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ABSTRACT 


Four  salvage  ships  and  four  ocean-going  towing  ships  are  maintained  and 
operated  by  the  Military  Sealift  Command  (MSC)  for  the  U.S.  Navy.  In  2019,  the  first  T- 
ATF  ships  will  reach  the  end  of  their  40-year  life  expectancy.  The  program  manager  for 
these  vessels  has  a  set  of  top-level  performance  characteristics  that  are  deemed  as 
desirable  requirements  for  a  new  ship  class,  encapsulating  both  legacy  ship  class 
capabilities. 

The  DoD  has  shifted  defense  planning  from  the  specific  service  requirements 
generated  system  (RGS)  acquisition  to  the  Joint  Capabilities  Integration  and 
Development  System  (JCIDS)  approach  that  focuses  more  on  how  adversaries  fight 
rather  than  whom  they  are  fighting.  This  thesis  explores  how  to  use  systems  architecting 
to  incorporate  the  capabilities  derived  from  strategic  guidance  into  a  Department  of 
Defense  Architecture  Framework  (DODAF)  product.  The  design  tool,  CORE,  is  used  to 
explain  the  architecting  methodology  and  produce  DODAF  vl.5  system  models  for 
decision  making  and  acquisition  requirement  generation. 
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EXECUTIVE  SUMMARY 


The  transformation  to  a  capabilities-based  approach  was  to  redefine  defense 
requirements  on  delivering  more  warfighting  capability,  focusing  on  how  our  adversaries 
fight,  rather  than  whom  the  adversary  may  be  or  where  the  war  might  occur.  The 
motivation  for  this  transformation  was  a  realization  across  many  levels  of  the  U.S. 
Department  of  Defense  (DoD)  that  systems  development  was  consistently  resulting  in 
outcomes  that  did  not  meet  the  needs  of  stakeholders,  both  from  the  single  service  and  the 
joint  perspective.  This  thesis  will  report  the  development  of  an  integrated  systems 
architecting  and  engineering  process,  focusing  on  the  systems  architecting  activities  in 
the  earliest  stages  of  an  integrated  architecture  development.  To  achieve  the 
development  of  a  truly  integrated  system,  the  needs  of  various  stakeholders  —  who  have 
their  own  cultures,  which  exhibit  conflicting  and  non-commensurate  objectives  —  must 
be  considered  in  the  approach.  The  field  of  architecture  deals  with  situations  as  part  of 
its  legacy,  and  has  been  defined  as  a  promising  area  in  which  to  augment  the  earliest 
stages  of  systems  engineering’s  well-defined  integration  of  the  two  methods.  Systems 
architecting  and  engineering  would  be  a  useful  process  in  developing  the  types  of 
integrated  architectures  envisioned  for  future  defense  systems. 

An  integrated  systems  architecting  and  engineering  process  is  an  iterative 
development  process  of  a  system  with  consideration  of  the  stakeholders’  needs  —  at  the 
highest  hierarchical  level,  all  the  way  down  to  individual  end  item  components  — 
through  the  projected  life  cycle.  A  top-down  iterative  approach  is  needed  for  the 
architecture  development  process,  flowing  from  the  system  or  system  of  systems  (SoS)  at 
the  highest  levels  and  down  to  the  lowest  levels  of  components.  Engineering  and 
architecting  take  two  very  different  approaches  to  the  development  of  systems. 
Engineering  is  a  deductive  method,  utilizing  quantifiable  analysis,  while  architecting  is 
an  inductive  process  dealing  with  non-quantifiable  processes.  The  distinction  between 
architecting  and  engineering  is  what  tools  or  tactics  are  used  to  resolve  issues.  The  range 
of  approaches,  to  both  the  art  and  the  science  embodied  in  the  two  approaches,  is  not  as 
far  removed. 
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The  Joint  Capabilities  Integration  Development  System  (JCIDS)  starts  the 
acquisition  as  a  joint  process  of  Strategic  Direction  and  develops  a  joint  perspective  of 
warfighting.  A  collaborative  assessment  and  analysis  of  Joint  Operational  Concepts 
identifies  integrated  architectures  to  facilitate  in  system  design.  The  operation  of  the 
JCIDS  process  and  the  Enterprise  Architecture  Hierarchy  will  require  the  systems 
architect  to  explore  the  intended  requirements  and  constraints  with  the  stakeholders  to 
seek  a  clear  set  of  objectives  to  which  all  could  agree  before  formulating  what  the 
optimal  outcome  might  be.  Architecture  frameworks  are  used  to  provide  a  consistent 
documentation  basis  to  describe  stakeholder  views.  The  Department  of  Defense 
Architecture  Framework  (DODAF)  is  the  basis  upon  which  the  products  in  this  thesis  are 
derived.  They  provide  enough  information  in  the  stakeholder’s  views  to  make  technical 
decisions. 

Both  the  T-ARS  and  T-ATF  class  ship  are  coming  to  the  end  of  their  service  life  of 
40  years.  Eight  vessels  of  a  single  hull  type  have  been  suggested  as  acceptable  risks  to 
accommodate  the  wartime  and  peacetime  capabilities  augmented  by  contracted  commercial 
tows.  This  thesis  describes  an  approach  for  structuring  the  performance  characteristics  from 
the  Supervisor  of  Diving  and  Salvage  (SUPSAEV),  creating  information  using  a  framework- 
based  approach,  in  this  case  DODAF.  The  goal  is  to  provide  a  clear  path  from  mission  area 
needs  to  requirements  to  be  clear  and  defined,  thereby  achieving  a  product  to  construct  assets 
to  perform  present  salvage  and  towing  operations  and  future  tasks. 

CORE  is  the  tool  used  to  assist  in  creating  the  architecture  element  relationships  that 
will  provide  the  architectural  products  to  support  stakeholder  decision  making.  The 
architecture  is  based  on  a  DODAF  vl.5  schema,  to  populate  a  database  of  element  classes, 
enabling  the  architect  to  define  relationships,  list  a  description,  show  hierarchies  and  various 
other  characteristics  The  salvage  and  towing  systems  architecture  development  is  initiated 
using  a  “Middle  Out”  method,  since  some  legacy  system  characteristics  are  known.  In  a 
“Middle  Out”  start  the  architecture  model  is  synthesized  beginning  with  the  legacy  system 
known  characteristics  and  requirements.  Strictly  speaking,  the  architecting  process  does  not 
typically  start  by  defining  the  form  of  the  future  system  as  a  ship,  aircraft,  or  any  other 
vehicle.  However,  in  this  particular  case,  the  end  item  has  already  been  named  a  T-ARS(X) 
class  of  ship. 
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I. 


MOTIVATION  FOR  SYSTEMS  ARCHITECTURE 


Our  Challenge  is  to  understand  how  to  integrate  design  and  production 
technology  into  an  acquisition  process  that  industry  can  execute.  This 
requires  a  deep  knowledge  of  systems  engineering  and  a  profound 
understanding  of  the  acquisition  process.  System  engineering  is  key  to 
ensuring  that  each  ship  is  configured  to  optimize  the  fleet...  All  this 
implies  a  need  for  integration  of  elements  and  capabilities  [1]. 


A.  BACKGROUND 

The  2001  Quadrennial  Defense  Review  (QDR)  directed  the  initiation  of  a 
capabilities-based  approach  to  defining  defense  requirements.  The  transformation  to  a 
capabilities-based  approach  is  to  deliver  more  warfighting  capability  based  on  how  our 
adversaries  fight,  rather  than  on  whom  the  adversary  may  be  or  where  the  war  might 
occur  [2],  The  motivation  for  this  transformation  was  a  realization,  across  many  levels  of 
the  U.S.  Department  of  Defense  (DoD),  that  systems  development  consistently  resulted  in 
outcome  that  did  not  meet  the  needs  of  stakeholders,  both  from  single  service  and  joint 
perspective,  from  end  users  to  program  managers  to  planners. 

What  happens  in  the  Department  of  Defense — and  it  runs  me  up  the  wall — 
is  each  service  comes  up  with  their  things... and  how  in  the  world  do  you 
get  those  four  things  into  a  single  fighting  force  at  the  end?  It ’s  a  train 
wreck... every  year  when  you’re  trying  to  do  a  budget.  It’s  just  a  meat 
grinder  trying  to  pull  things  together  because  they  didn’t  start  coming 
together  earlier  at  a  lower  level.  And  we’re  going  to  fix  that.  I’ll  be  the 
meat  grinder  [3]. 

The  method  of  developing  systems  referred  to  by  Secretary  Rumsfeld  is  typically 
known  as  the  Requirements  Generating  System  (RGS),  and  is  shown  on  the  left  side  of 
Figure  1  —  a  bottom  up,  ‘stovepiped’  method  that  only  captured  the  originating  services 
‘needs.’  The  vision  of  warfighting  was  generated  by  the  individual  service’s  scenarios  of 
fighting  assuming  no  other  services  would  play  a  part.  The  right  side  of  Figure  1 
represents  the  new  systems  development  process,  called  the  Joint  Capabilities  Integration 
Development  System  (JCIDS),  which  starts  the  acquisition  as  a  joint  process  of  Strategic 
Direction  and  develops  a  joint  perspective  warfighting  vision  [2], 
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Figure  1.  Capability-Based  Approach  From  [2] 


The  joint  vision  for  military  strategy  is  shown  in  Figure  2  and  describes  the 
JCIDS  process  —  an  approach  that  utilizes  the  expertise  of  all  government  agencies  to 
exploit  existing  capabilities  and  develop  new  capabilities  to  close  gaps.  The 
collaborative  assessment  and  analysis  of  Joint  Operational  Concepts  identifies  integrated 
architectures  to  facilitate  in  system  design  [4],  In  order  to  achieve  the  development  of  a 
truly  integrated  system,  the  needs  of  various  stakeholders  —  who  have  their  own 
cultures,  which  exhibit  conflicting  and  non-commensurate  objectives  —  an  approach 
must  be  used  that  allows  for  consideration  of  this  reality.  The  discipline  of  systems  has 
traditionally  been  applied  to  such  development  processes,  but  this  method  is  limited  in 
the  fuzzy  front  end  of  the  process,  especially  in  the  explicit  consideration  of  the 
incorporation  of  stakeholder  needs  and  desires,  and  in  the  ability  to  effectively  model  the 
connection  of  these  needs  to  an  ability  to  synthesize  creative  thinking  in  an  abstract, 
solution-neutral  sense.  The  field  of  architecture  deals  with  the  situations  as  part  of  its 
legacy,  and  has  been  defined  as  a  promising  area  in  which  to  augment  the  earliest  stages 
of  systems  engineering  [5],  A  well-defined  integration  of  the  two  methods,  systems 
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architecting  and  engineering,  would  be  useful  process  in  developing  the  types  of 
integrated  architectures  envisioned  for  future  defense  systems. 


pperstfe  rraf 
PorrgeptP 


Lw  .1^ J 

JV. 


ftrefrftetfuree 


•  Construct  for  analysis 

Analytical  tool  to  identify  and  articulate 
our  requirements 


Figure  2.  DOD  Development  Process  From  [6] 

B.  SYSTEMS  ARCHITECTING  AND  ENGINEERING 

An  integrated  systems  architecting  and  engineering  process  is  an  iterative 
development  process  of  a  system  with  consideration  of  the  stakeholders’  needs  —  at  the 
highest  hierarchical  level  all  the  way  down  to  individual  end  item  components  —  through 
the  projected  life  cycle.  A  system  is  an  integrated  set  of  elements  that  accomplishes  a 
defined  objective  [7],  Further,  a  system  of  system  (SoS)  is  a  set  of  interdependent 
systems  that  are  related  or  connected  to  provide  a  given  capability  [8]. 

Systems  engineering  is  defined  by  INCOSE  as  "a  branch  of  engineering  whose 
responsibility  is  creating  and  executing  an  interdisciplinary  process  to  ensure  that 
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customer  and  stakeholder's  needs  are  satisfied  in  a  high-quality,  trustworthy,  cost- 
efficient  and  schedule-compliant  manner  throughout  a  system's  entire  life  cycle,  from 
development  to  operation  to  disposal  [7].”  Systems  engineering  is  generally  used  to 
describe  the  set  of  processes  applied  to  the  development  of  systems  and  spans  activities, 
from  customer  need  discovery,  completely  through  to  realization  and  eventual  disposal 
and  recycling.  While  this  description  encompasses  the  entire  life  cycle  of  a  product 
development,  it  is  perhaps  too  broad  in  that  the  knowledge,  skills,  and  abilities  needed  to 
perform  the  process  are  different  in  the  early  stages,  as  opposed  to  the  later  stages. 

Systems  architecting,  extending  the  traditional  definition  of  architecting,  deals 
primarily  with  ill-structured  situations  with  non-measurable  quantities  and  non- 
quantitative  tools  and  guidelines,  making  it  well-suited  for  the  early  stages  of  systems 
engineering. 

Systems  architecting  and  systems  engineering  present  complementary 
approaches  to  the  development  of  SoS.  For  capability-based  development 
of  unprecedented  systems,  the  initial  portions  of  the  traditional  systems 
engineering  process  have  been  demonstrated  to  show  unsatisfactory 
results,  in  particular  due  to  the  complexity  in  transforming  ill-defined 
capabilities  into  requirements  useful  enough  to  begin  any  engineering- 
based  design.  A  capability  is  defined  as  “The  ability  to  achieve  a  desired 
effect  under  specified  standards  and  conditions  through  combinations  of 
means  and  ways  to  perform  a  set  of  tasks.  ”  In  the  architecting  process, 
capabilities  are  represented  as  operational  activities  that  are  modeled  and 
simulated  in  executable  form  as  behavioral  entities.  While  recognition  of 
focus  on  capabilities-driven  systems  architecting  has  given  rise  to  the 
fairly  recent  development  of  system  architecting  methods,  frameworks, 
and  processes,  what  is  lacking  at  this  time  is  a  defined  method  for 
architecting  -  the  development  of  the  architecture  itself  [9]. 

For  capability-based  acquisition,  the  system  architecting  and  engineering  process 
is  utilized  for  the  iteration  and  decomposition  of  Operational  Concepts  to  capabilities, 
then  capabilities  to  system  requirements,  and  further  decomposition  to  end  items.  Figure 
3  shows  a  hierarchal  view  of  how  the  system  engineering  plan  is  carried  through  each 
level,  translating  needed  capabilities  to  functional  systems  and  systems  of  systems  (SoS). 
A  recent  USD  (AT&L)  (Under  Secretary  of  Defense,  Acquisition,  Technology  and 
Logistics)  memorandum  establishes  systems  engineering  policy  and  mandates  systems 
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engineering  for  all  programs.  This  memorandum  is  included  in  the  latest  revision  to  DoD 
Instruction  5000.2.  An  extract  from  the  memorandum  follows: 

Systems  Engineering  (SE).  All  programs  responding  to  a  capabilities  or 
requirements  document,  regardless  of  acquisition  category,  shall  apply  a 
robust  SE  approach  that  balances  total  system  performance  and  total 
ownership  costs  within  the  family-of-systems,  systems-of-systems  context. 
Programs  shall  develop  a  Systems  Engineering  Plan  (SEP)  for  MDA 
(Milestone  Decision  Authority)  approval  in  conjunction  with  each 
Milestone  review,  and  integrated  with  the  Acquisition  Strategy.  This  plan 
shall  describe  the  program's  overall  technical  approach,  including 
processes,  resources,  metrics,  and  applicable  performance  incentives.  It 
shall  also  detail  the  timing,  conduct,  and  success  criteria  of  technical 
reviews  [10]. 
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Figure  3.  System  Engineering  Hierarchy  From  [11] 
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A  more  detailed  description  of  the  hierarchy  shown  in  Figure  3  is  contained  in  the 
Department  of  the  Navy  Enterprise  Architecture,  Figure  4.  At  the  highest  level,  this 
hierarchy  has  four  mission  areas  that  categorize  portfolios  or  SoS.  These  portfolios  are 
then  subdivided  as  capability  areas  that  are  mapped  to  the  Naval  Power  21  (NP21)  pillars 
to  provide  a  crosswalk  to  Navy  Budgeting  categories.  The  Warfighting  Mission  Area 
(WMA)  is  managed  by  the  Chairman  Joint  Chiefs  of  Staffs  (CJCS),  who  manages  the 
portfolios  through  the  JCIDS  process  and  provides  input  to  the  Planning,  Programming, 
Budgeting,  and  Execution  (PPBE)  system  and  Defense  Acquisition  System  (DAS) 
processes.  Each  sub-portfolio  contains  Joint  Capability  Area  (JCA),  which  are  mapped  to 
the  Navy  Required  Operational  Capabilities  (ROC).  The  ASN  RDA  Chief  Systems 
Engineer  has  assigned  a  Mission  Area  Chief  Engineer  (MA  CHENG)  to  each  JCA  for 
configuration  control.  Figure  4  illustrates  how  systems  and  SoS  are  tied  to  the  DoD 
Mission  Areas;  the  context  of  this  thesis  concerns  architecting  the  systems  tied  to  JCAs 
[12]. 
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Figure  4.  Department  of  Navy  Enterprise  Architecture  Hierarchy  From  [12] 

In  regard  to  the  architecting  process  to  achieve  this  SoS  outcome  —  beyond  a 
very  short  summary  of  several  systems  engineering  approaches  in  the  DODAF  —  there  is 
no  well-defined  method  detailed  on  how  to  create  an  architecture  that  addresses  overall 
capabilities,  concepts  of  operations,  and  requirements  to  formulate  design  considerations 
for  engineering  a  system  or  SoS  in  an  enterprise  architecture  framework. 

C.  SUMMARY 

This  thesis  will  report  the  development  of  an  integrated  systems  architecting  and 

engineering  process,  focusing  on  the  systems  architecting  activities  in  the  earliest  stages 
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of  an  integrated  architecture  development.  The  method  will  be  applied  to  an  architecture 
that  directly  addresses  the  recapitalization  of  a  future  towing  and  salvage  ship.  The 
overall  context  of  the  SoS  integrated  architecture  is  taken  down  to  a  system  level,  through 
an  example  applied  to  a  specific  ship  platform,  to  accomplish  towing  and  salvage 
capabilities.  The  process  of  identifying  a  capability  gap  or  need,  defining  architecture 
and  engineering  requirement  specifications,  analyzing  system  functions,  and  allocation  to 
system  physical  components  is  completed,  including  development  of  all  architecture 
elements  and  the  creation  of  architecture  framework  products. 
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II.  SYSTEM  ARCHITECTURE  AND  THE  ARCHITECTURING 

PROCESS 


Architecting,  the  planning  and  building  of  structures,  is  as  old  as  human 
societies —  and  as  modern  as  the  exploration  of  the  solar  systems  [5], 


A  INTRODUCTION 

Considering  the  operation  of  the  JCIDS  process  and  the  Enterprise  Architecture 
Hierarchy,  a  top-down  iterative  approach  is  needed  for  the  architecture  development 
process  —  flowing  from  the  system  or  system  of  systems  (SoS)  at  the  highest  levels,  all 
the  way  down  to  the  lowest  level  of  components.  This  chapter  describes  the  background 
and  key  aspects  surrounding  the  need  for  the  development  of  an  architecture 
(architecting),  its  relationship  to  the  integration  with  systems  engineering,  and  the  various 
characteristics  of  what  constitutes  an  architecture. 

B.  CONSIDERATION  OF  SYSTEMS  ENGINEERING  AND 

ARCHITECTING 

Engineering  and  architecting  take  two  very  different  approaches  to  the 

development  of  systems  [7],  In  traditional  systems  engineering  terminology,  early  stage 

tasks  have  been  often  referred  as  “requirements  capture,”  “requirements  generation,” 

“requirements  definition,”  and  “architectural  design”  in  an  attempt  to  define  the  overall 

early-stage  design  objective.  Engineering  is  a  deductive  method,  utilizing  quantifiable 

analysis  to  deal  primarily  with  physical  and  scientific  situations  with  measurable 

quantities  and  concepts.  Architecting,  on  the  other  hand,  is  an  inductive  process  dealing 

with  non-quantifiable  processes,  taking  into  consideration  the  desires  and  needs  of 

stakeholders  who  express  themselves  in  their  native  language  using  abstract,  subjective 

expressions.  The  distinction  between  architecting  and  engineering  is  what  tools  or  tactics 

are  used  to  resolve  issues.  The  range  of  approaches  to  both  the  art  and  the  science 

embodied  in  the  two  approaches  are  not  as  far  removed.  For  instance,  in  systems 

engineering,  the  requirements  may  be  ill-structured  due  to  the  customer’s  optimal  goal 

not  being  fully  realized.  The  architecting  approach  would  be  to  jointly  explore  the 
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intended  requirements  and  constraints  with  the  stakeholders  to  seek  a  clear  set  of 
objectives  to  which  all  could  agree  before  formulating  what  the  optimal  outcome  might 
be.  Figure  5  summarizes  the  fundamental  differences. 
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Figure  5.  Comparison  of  Architecting  and  Engineering.  From[13]. 


C.  SYSTEMS  ARCHITECTING  APPROACH 

An  architecture  exists  for  the  purpose  of  achieving  a  well-defined  system  in  the 
application  domain  to  achieve  the  eventual  system  developed  in  the  solution  domain  that 
can  be  used  to  meet  desired  capabilities  over  a  specific  time  frame  or  set  of  time  frames 
[5],  An  architecture  includes  elements  and  interconnections;  how  they  interrelate  is  the 
key  to  an  effective  design.  Boundaries  are  necessary  to  contain  the  architecture  to  its 
context  and  help  to  define  how  it  interacts  with  the  external  environment.  Architecting  is 
a  process  consisting  of  methods,  tools,  and  people  implemented  to  develop  the  system 
architecture. 

The  architecting  process  is  one  of  participative  discovery.  The  architect 

continually  works  with  all  stakeholders  to  define  the  architecture,  continuously  working 

to  resolve  ambiguity,  reduce  complexity  and  focus  creativity,  taking  the  initial  capability 

need  (or  “idea”),  from  the  abstract  to  the  concrete  through  a  series  of  ever-evolving 

models  of  continually  improved  fidelity.  The  architect  uses  architecting  principles, 

model-based  systems  principles  and  activities  to  define,  develop,  integrate,  and  evolve 
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the  operational  and  system  models.  For  DoD,  architecting  is  guided  by  the  JCIDS 
process,  entering  into  acquisition  in  the  earliest  part  of  the  concept  refinement  stage. 
Architecting  the  capabilities  is  a  dynamic  part  of  the  early-stage  process  and  differs  in 
that  they  should  not  be  considered  as  initial  requirements. 

Systems  architecting  combines  working  with  the  stakeholders  in  the 
conceptualization  process  to  identify  requirements  for  the  development  community  in 
pursuit  of  eventual  technical  optimization  [5],  The  continually  maturing  of  the 
stakeholder  needs,  into  the  eventual  requirements  specifications,  demands  a  well-refined 
set  of  documents  and  models  for  the  later  stages.  To  support  a  well-defined  set  of 
deliverables  for  the  architecting  process,  frameworks  have  been  defined,  along  with 
supporting  views  and  products. 

D.  ARCHITECTURE  FRAMEWORKS 

Every  system  has  an  architecture  that  fulfills  a  mission.  Architecture  frameworks 
are  used  to  provide  a  consistent  documentation  basis  to  describe  an  architecture. 
Zachman  (1987)  was  one  of  the  first  to  define  architecture  in  terms  that  can  apply  to  any 
object,  not  just  civil  engineering.  The  intent  of  the  Zachman  framework  is  to  establish  a 
common  vocabulary,  defining  complex  enterprise  systems.  The  Department  of  Defense 
developed  the  C4ISR  Architecture  Framework  (C4ISRAF)  based  on  Zachman’ s 
philosophy.  The  C4ISRAF  was  eventually  expanded  in  scope  and  re-titled  the 
Department  of  Defense  Architecture  Framework  (DODAF)  for  use  in  development  of  all 
DoD  system  architectures.  In  the  commercial  community,  The  Open  Group  Architectural 
Framework  (TOGAF)  uses  open  systems  building  blocks  for  mission-critical  business 
applications.  In  response  to  the  Clinger-Cohen  Act  (1996),  the  Federal  Chief  Information 
Officers  (CIO)  Council  developed  the  Federal  Enterprise  Architecture  Framework 
(FEAF)  to  guide  in  sharing  of  federal  information.  Other  architectural  frameworks  have 
been  established  in  NATO  and  other  countries,  such  as  UK  Ministry  of  Defense 
Architectural  Framework  (MODAF)  and  the  Department  of  National  Defense 
Architecture  Framework  (DNDDAF),  for  procuring  and  integrating  their  respective 
defense  systems  architectures  [14]. 
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At  its  core,  the  Zachman  Framework  for  Enterprise  Architecture  (Figure  6) 
recognizes  that  the  stakeholders  see  a  system  from  their  own  perspective,  and  that  they 
have  different  views  of  the  end  product.  Similarly,  any  architecture  should  develop  these 
views  to  enhance  stakeholder  understanding  of  the  system  or  business  model. 

•  Strategists  and  Decision  Authority  view  of  the  system  is  used  to  evaluate 
doctrine  to  conceptualize  a  capability  or  capability  gap. 

•  Planner  view  of  the  capability  concept  is  an  analysis  through  the  Joint 
Capabilities  Integration  and  Development  System  (JCIDS)  process. 
Although  iterative,  and  not  in  a  hierarchical  design  within  concept 
definition,  a  capability  need  is  defined. 

•  Designer/Architect  view  is  used  to  produce  capability  architecture  for 
Builders  to  develop  and  engineer. 

•  Operator  views  are  used  for  capability  employment. 
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THE  ZACHMAN  FRAMEWORK  FOR  ENTERPRISE  ARCHITECTURE 


Figure  6.  Zachman  Framework  for  Enterprise  Architecture  From[15] 


The  architecting  process  must  be  configured  to  create  and  illustrate  these  views 
and  include  the  ability  to  allow  for  an  iterative  process  of  discovery  in  meeting  emerging 
capability  needs.  Implementation  of  this  capability-based  development  process  is  the 
front  end  to  the  system  acquisition  and  development  process,  and  is  an  attempt  to  provide 
a  sound  basis  for  beginning  a  systems  engineering  approach  to  development  by  keeping 
the  early-stage  process  focused  on  the  problem  space  and  not  the  solution  space  (Figure 
7).  The  architect  can  refine  the  initial  concept  of  the  system  to  have  a  better  definition  of 
how  it  fulfills  the  mission.  As  each  iteration  is  developed,  the  conceptual  model  of  the 
architectural  description  will  depict  how  the  architect  should  design  a  solution  space  from 
the  problem  space.  The  role  of  the  architect  is  to  understand  the  scope  and  context  of 
each  stakeholder’s  concerns.  Each  concern  establishes  viewpoints  that  need  to  be 
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modeled.  As  the  architecture  evolves  into  a  design,  the  actual  view  is  different  with  each 
stakeholder.  The  architecture  should  capture  the  thoughts  of  the  stakeholders  as  they 
pertain  to  the  element  described  in  its  environmental  use.  Concurrently,  the  design 
should  consider  the  internal  components  and  their  interfaces  and  arrangements  (Work 
Breakdown  Structures)  to  fulfill  the  contractor's  needs  to  build  the  system  while 
balancing  the  interests  of  the  stakeholders. 
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Figure  7.  Problem  and  Solution  Space  for  Systems  Architecting  and  Engineering 

From  [16]. 


The  architecture  for  a  system  should  be  described  in  a  language  native  to  different 
stakeholders.  The  stakeholders’  views  are  concerns  that  identify  the  architectural 
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description.  As  stated  before,  the  stakeholders’  viewpoints  are  different,  dependent  on 
the  objective  and  resources  of  the  stakeholder.  A  model  provides  a  rationale  for  the 
architecture.  Figure  8  is  the  IEEE  1471  conceptual  framework  to  describe  an  architecture 
[16]. 


Figure  8.  Conceptual  model  of  the  architectural  description.  From[16] 

This  diagram  describes  the  relationship  among  all  aspects  that  constitute 
architecture.  To  summarize  what  is  meant  by  the  model,  some  key  relationships  are 
described.  Every  system  fulfills  a  mission,  while  at  the  same  time  that  system  has  an 
architecture,  which  is  in  turn  described  by  an  architecture  description,  which  provides  a 
rationale  as  well  as  an  identified  set  of  stakeholders.  The  architecture  description  is 
organized  by  a  set  of  views  that  conform  to  stakeholder  viewpoints.  Finally,  views  are 
consistent  with  models,  which  are  used  to  create  various  aspects  of  the  system.  There  is 
an  underlying  basis  of  any  system  —  the  architecture  —  and  the  views  are  critically 

important  to  make  sure  stakeholders  can  see  their  needs  are  being  met. 
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E.  ARCHITECTURE  VIEWS 


The  DoD  5000.2  states  that  each  integrated  architecture  shall  have  three  views: 
operational,  systems,  and  technical  standards. 

...as  defined  in  the  current  Architectural  Framework  guidance  and  have 
direct  relationships  to  DoD  Component-developed  functional  area 
integrated  architectures.  The  Joint  Staff  (or  Principal  Staff  Assistant 
(PSA)  for  business  areas)  shall  lead  development  of  the  operational  view, 
in  collaboration  with  the  Services,  Agencies,  and  Combatant 
Commanders,  to  describe  the  joint  capabilities  that  the  user  seeks  and  how 
to  employ  them.  The  USD  (AT&L)  (or  PSA  for  business  areas)  shall  lead 
development  of  the  systems  view,  in  collaboration  with  the  Services, 
Agencies,  and  Combatant  Commanders,  to  characterize  available 
technology  and  systems  functionality.  The  systems  view  shall  identify  the 
kinds  of  systems  and  integration  needed  to  achieve  the  desired  operational 
capability.  The  DoD  Chief  Information  Officer  (CIO)  shall  lead  the 
development  and  facilitate  the  implementation  of  the  Global  Information 
Grid  Integrated  Architecture,  which  shall  underpin  all  mission  area  and 
capability  architectures.  The  Military  Departments  and  Defense  Agencies 
shall  participate  in  the  identification  of  the  appropriate  technical  view 
consisting  of  standards  that  define  and  clarify  the  individual  systems 
technology  and  integration  requirement  [17]. 

Figure  9  shows  the  relationships  of  the  views.  The  purpose  to  develop  a  broad- 
based  “big-picture”  aspect  of  multiple  views  of  the  system  as  the  architect  documents  key 
factors  to  apply  insight  for  design,  with  all  views  being  derived  from  one  single 
architecture  description.  Each  view  encapsulates  a  complete  representation  of  the 
particular  perspective  and  is  consistent  with  respect  to  other  views. 
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Conventions 


!  mpiomeniattan'Proajrieniern 
of  the  Selected  System  Capabilities 

Figure  9.  Linkage  among  views.  From[18]. 


The  Operational  View  (OV)  is  essentially  the  user  or  operator  view;  describing 
tasks,  operational  elements,  and  mission  needs.  Driven  by  document  or  emerging 
concepts,  the  OV  shows  how  the  system  actually  operates.  The  OV  identifies  conceptual 
processes  for  business  and  intended  uses  for  the  architecture  being  developed.  It  defines 
the  ‘what  and  who’  of  a  system,  and  the  frequency  and  type  of  information  to  be 
exchanged  to  fulfill  the  mission. 

A  Systems  View  (SV)  is  one  that  focuses  on  the  infrastructure  and  connections 
among  system  described  in  the  OV.  The  DoD  warfighting  and  business  functions  are 
related  to  the  operational  needs  to  identify  specific  system  capabilities.  The  SV  identifies 
specific  technologies  and  systems;  these  technologies  and  systems  can  be  emerging  or 
mature.  For  example,  this  view  is  what  a  homebuilder  would  use  to  emphasize  electrical, 
water,  sewer,  and  entertainment/communication  systems. 
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The  Technical  View  (TV)  elaborates  on  the  policies  and  standards  set  forth  to 
govern  the  system  being  architected.  TV  delineates  the  technical  implementation  criteria 
to  which  the  system  or  SOS  should  comply.  The  DODAF  explains  TV  as  a  way  to 
promote  efficiency  and  interoperability  [18]. 

The  view  that  illustrates  all  three  views  at  once  is  called  an  All  Views  (AV), 
which  reflect  the  entire  architecture  as  a  “Big  Picture.”  AVs  capture  the  scope,  purpose, 
intended  users,  and  environment  for  which  the  system  or  SoS  will  be  designed.  This 
would  include  the  subject  area  and  time  frame  for  the  architecture. 

As  these  views  are  derived  from  a  common  set  of  architectural  relationships,  an 
integrated  approach  is  in  place  for  development  of  a  systems  requirements  governed  by 
technical  standards  —  as  long  as  the  basis  set  of  element  relationships  is  consistently 
refined. 

F.  ARCHITECTURE  PRODUCTS 

The  DODAF  uses  architecture  products  in  describing  the  architectural 
information.  Table  1  shows  a  list  of  DODAF  views  identified  for  a  standardized 
approach  in  identifying  an  integrated  architecture.  Additional  products  could  be  made, 
but  should  follow  these  same  guidelines.  The  first  column  gives  the  applicable  view,  the 
second  column  provides  the  alphanumeric  reference  identifier,  the  third  column  is  the 
formal  name,  and  the  last  column  is  a  general  description  of  the  product.  The  list  does 
not  imply  a  specific  order  that  one  must  use  to  generate  products.  The  architectural 
products  used  are  specific  to  the  situation,  scope,  and  objectives  to  be  met. 

The  actual  framework  for  which  these  products  are  derived  must  provide  enough 
information  —  in  the  stakeholder’s  views  — to  make  technical  decisions.  The  descriptive 
methodology  must  identify  capability  needs,  subsequently  relating  them  to  systems 
development.  The  use  of  architectures  has  been  specifically  addressed  in  the  JCIDS 
process  as  Mandatory  Appendices  in  the  Initial  Capabilities  Document  (ICD),  Capability 
Development  Document  (CDD),  Capability  Production  Document  (CPD),  and  Capstone 
Requirements  Document  (CRD)  [8],  Table  2  lists  the  DODAF’s  recommendations  for 
architecture  products  supporting  decision  making  for  a  number  of  processes. 
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Applicable 

View 

Framework 

Product 

Framework  Product  Name 

General  Description 

All  Views 

AV-1 

Overview  and  Summary 
Information 

Scope,  purpose,  intended  users,  environment  depicted, 
analytical  findings 

All  Views 

AV-2 

Integrated  Dictionary 

Architecture  data  repository  with  definitions  of  all  terms  used  in 
all  products 

Operational 

OV-1 

High-Level  Operational 

Concept  Graphic 

High-level  graphical/textual  description  of  operational  concept 

Operational 

OV-2 

Operational  Node  Connectivity 
Description 

Operational  nodes,  connectivity,  and  information  exchange 
needlines  between  nodes 

Operational 

OV-3 

Operational  Information 

Exchange  Matrix 

Information  exchanged  between  nodes  and  the  relevant 

attributes  of  that  exchange 

Operational 

OV-4 

Organizational  Relationships 
Chart 

Organizational,  role,  or  other  relationships  among 
organizations 

Operational 

OV-5 

Operational  Activity  Model 

Capabilities,  operational  activities,  relationships  among 
activities,  inputs,  and  outputs;  overlays  can  show  cost, 
performing  nodes,  or  other  pertinent  information 

Operational 

OV-6a 

Operational  Rules  Model 

One  of  three  products  used  to  describe  operational  activity- 
identities  business  rules  that  constrain  operation 

Operational 

OV-6b 

Operational  State  Transition 

Description 

One  of  three  products  used  to  describe  operational  activity- 

identities  business  process  responses  to  events 

Operational 

OV-6C 

Operational  Event-T race 

Description 

One  of  three  products  used  to  describe  operational  activity- 

traces  actions  in  a  scenario  or  sequence  of  events 

Operational 

OV-7 

Logical  Data  Model 

Documentation  of  the  system  data  requirements  and  structural 

business  process  rules  of  the  Operational  View 

Systems 

SV-1 

Systems  Interface  Description 

Identification  of  systems  nodes,  systems,  and  system  items 
and  their  interconnections,  within  and  between  nodes 

Systems 

SV-2 

Systems  Communications 

Description 

Systems  nodes,  systems,  and  system  items,  and  their  related 

communications  lay-downs 

Systems 

SV-3 

Systems- Systems  Matrix 

Relationships  among  systems  in  a  given  architecture;  can  be 

designed  to  shew  relationships  of  interest,  e.g.,  system-type 
interfaces,  planned  vs.  existing  interfaces,  etc. 

Systems 

SV-4 

Systems  Functionality 
Description 

Functions  performed  by  systems  and  the  system  data  flows 
among  system  functions 

Systems 

SV-5 

Operational  Activ  ity  to  Systems 
Function  Traceability  Matrix 

Mapping  of  systems  back  to  capabilities  or  of  system  functions 
back  to  operational  activities 

Systems 

SV-6 

Systems  Data  Exchange  Matrix 

Provides  details  of  system  data  elements  being  exchanged 

between  systems  and  the  attributes  of  that  exchange 

Systems 

SV-7 

Systems  Performance 
Parameters  Matrix 

Performance  characteristics  of  Systems  View  elements  for  the 
appropriate  time  frame(s) 

Systems 

SV-8 

Systems  Evolution  Description 

Planned  incremental  steps  toward  migrating  a  suite  of  systems 

to  a  more  efficient  suite,  or  toward  evolving  a  current  system  to 
a  future  implementation 

Systems 

SV-9 

Systems  Technology  Forecast 

Emerging  technologies  and  software/hardware  products  that 

are  expected  to  be  available  in  a  given  set  of  time  frames  and 
that  will  affect  future  development  of  the  architecture 

Systems 

SV-lOa 

Systems  Rules  Model 

One  of  three  products  used  to  describe  system  functionality- 

identities  constraints  that  are  imposed  on  systems  functionality 
due  to  some  aspect  of  systems  design  or  implementation 

Systems 

SV-1  Ob 

Systems  State  Transition 

Description 

One  of  three  products  used  to  describe  system  functionality- 

identities  responses  of  a  system  to  events 

Systems 

SV-IOc 

Systems  Event-Trace 

Description 

One  of  three  products  used  to  describe  system  functionality- 
identities  system- specific  refinements  of  critical  sequences  of 
events  described  in  the  Operational  View 

Systems 

SV-11 

Physical  Schema 

Physical  implementation  of  the  Logical  Data  Model  entities, 
e.g.,  message  formats,  file  structures,  physical  schema 

Technical 

TV-1 

Technical  Standards  Profile 

Listing  of  standards  that  apply  to  Systems  View  elements  in  a 
given  architecture 

Technical 

TV-2 

Technical  Standards  Forecast 

Description  of  emerging  standards  and  potential  impact  on 

current  Systems  View  elements,  within  a  set  of  time  frames 

Table  1.  List  of  architecture  products.  From[19] 
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APPLICABLE  ARCHITECTURE  PRODUCTS 


All 

View 

Operational  View  (OV) 

Systems  View  (SV) 

Tech 
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View 

1  2 

1  1  2  |  3  4  f  5  |  6  |  7 

1  |  2  |  3  |  4  |  5  |  $|  7  [  8  |  9  1 10 1 1 1 

dll 

RECOMMENDED  USES  OF  ARCHITECTURE: 


1  P  la  n  n  i  na .  P  roa  r a  m  m  i  n  a  B  u  daet  i  n  a  Exec  ut  ion  P  r oc  e  ss  1 

CapabilityBased  Analysis  for  U  Investment  Decisions 

• 

• 

• 

• 

• 

t 

• 

• 

0 

• 

® 

• 

• 

• 

• 

• 

• 

• 

• 

Modernization  Planning  and  Technology  Insertion/Evolution 

• 

• 

© 

• 

® 

• 

• 

® 

® 

• 

• 

• 

• 

• 

Portfolio  Management 

• 

• 

• 

• 

• 

• 

• 

1  Joi  lit  C  a  pa  bi  lit  ies  1  nteq  ration  a  n  d  Be  vel  op  inent  System  I 

JCDDS  Analysis  fFAA  FNAt  FSA) 

|*  •I*!#! |*|®|  |®|«|  |  |  |  |  |  |®|  || 

ICD/CDD/CPD/C  RD 

□ 

□ 

□ 

□ 

□ 

Tip  giBtnnBM  ■  u 

Analysis  of  Alternative s^oA) 

1*1®  1®  !•  1  •  1  ®  1®  1®  1®  1  1  |®|©| 

|  Acquisition  Process 

Acquis  ion  Strategy 

• 

• 

• 

• 

® 

® 

□ 

• 

□ 

C4ISP 

□□ 

i 

□ 

0 

i 

□ 

0 

System  Design  and  Development 

• 

• 

• 

• 

• 

□ 

•" 

• 

• 

T 

• 

• 

• 

® 

® 

□ 

® 

Interoperability  and  Supportability  of  NSS  and  IT  Systems 

• 

• 

• 

• 

• 

® 

0 

0, 

□ 

® 

• 

• 

• 

• 

® 

® 

0 

0 

□ 

0 

Integrated  Test  &  Evaluation 

• 

• 

•j 

• 

® 

• 

® 

□ 

• 

• 

• 

• 

• 

• 

© 

□ 

|  Operations  (Assessment,  Planning,  Execution. 

Operations  Planning  &  Execution 

• 

• 

• 

t 

• 

• 

• 

• 

• 

® 

• 

0 

© 

CONORS  &  TIP 

• 

• 

• 

• 

• 

• 

• 

Communications  Plans 

• 

• 

• 

0 

® 

• 

• 

© 

® 

• 

Exercise  Planning  &  Execution 

• 

i 

• 

T 

• 

• 

¥ 

• 

• 

¥ 

¥ 

¥ 

¥ 

© 

Organizational  Design 

• 

• 

• 

• 

• 

• 

0 

¥ 

® 

0 

BFR/FFI 

• 

• 

• 

• 

• 

• 

® 

_ 


blank 


Product  is  highly  applicable 
Product  Is  often  or  partially  applicable 
Product  is  specifically  addressed  in  policy 
Product  is  required  for  an  Integrated  architecture 
Product  Is  usually  not  applicable 


Table  2.  Architecture  Products  by  use.  From[19] 


G.  SUMMARY 

The  architecture  consists  of  basis  description  of  the  elements  and  their 
relationships.  The  architecture  framework  defines  a  set  of  views  that  show  the  system  in 
the  stakeholders’  native  language.  The  views  are  all  derived  from  the  elements  and 
relationships,  so  they  accurately  represent  the  system.  This  conceptual  model  of  the 
element  relationships,  along  with  the  series  of  views,  provides  the  necessary  information 
to  begin  what  is  typically  the  beginning  of  the  traditional  systems  engineering  process. 
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III.  SALVAGE  AND  TOWING  BACKGROUND 


Navy  diving  -  performance  under  pressure. 
—  navydiver.org 


A.  INTRODUCTION 

This  chapter  will  give  a  brief  explanation  of  how  the  U.S.  Navy  Salvage  and 
Towing  community  is  organized.  It  will  also  present  a  brief  history  of  salvage  and 
towing  ship  classes,  describing  their  utility  to  the  military.  Finally,  this  chapter 
emphasizes  a  motivation  for  recapitalizing  the  current  fleet  of  salvage  and  towing  vessels. 

B.  U.S.  NAVY  SALVAGE  COMMUNITY 

The  Salvage  Facilities  Act  (10  U.S.C.  7361-637)  authorizes  the  Secretary  of  the 
Navy  to  have  a  Salvage  program.  It  allows  for  the  maintenance  of  a  national  salvage 
capability  for  use  in  peacetime,  war,  or  a  national  emergency  [20],  Salvage  forces  have 
unique  tasks  that  require  specialized  equipment  and  highly  trained  personnel.  The 
collaboration  with  the  Military  Sealift  Command  (MSC)  enables  the  Navy  to  provide 
salvage  and  towing  capabilities.  The  ‘triad’  of  U.S.  Navy  Salvage  forces  integrates 
Mobile  Diving  and  Salvage  Unit  (MDSU),  MSC,  and  Supervisor  of  Salvage  and  Diving 
(SUPALV,  NAVSEA  00C).  They  serve  as  the  core  for  removing  hazards  of  navigation 
(in  foreign  and  domestic  coastal  waters),  repairing  and  towing  damaged  vessels, 
recovering  sensitive  items  (such  as  aircraft  black  boxes),  and  recovering  other  high-value 
objects  from  the  ocean  depths.  These  are  a  few  examples  of  the  tasks  of  these  organic 
forces  within  the  Department  of  the  Navy  and  the  requests  from  federal  and  civilian 
entities  through  the  request  for  forces  (RFF)  process  to  the  prospective  service  command. 
Although  each  functional  element  of  the  salvage  triad  works  jointly  for  both  salvage  and 
towing,  each  has  a  separate  organizational  structure  [21]. 

SUPSALV  is  an  agency  (Code  00C)  of  Naval  Sea  Systems  Command 
(NAVSEA);  which  is  not  in  the  operational  chain  of  command.  For  salvage  operations 
directed  by  the  Chief  of  Naval  Operations,  SUPSALV  is  tasked  as  operational  control. 
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Furthermore,  SUPSALV  is  the  technical  authority  for  all  U.S.  Navy  diving  and 
authorizes  any  equipment  used.  In  the  instance  that  personnel  or  equipment  assets  are  not 
available,  SUPSALV  maintains  and  exercises  all  diving  and  salvage  contracts.  For  deep 
ocean  recovery  and  emergent  ship  salvage  material,  SUPSALV  maintains  and  exercises 
government-owned,  contractor-operated  (GO-CO)  equipment  and  capabilities  to  provide 
recovery  of  objects  to  a  depth  of  at  least  20,000  feet,  ship  salvage,  pollution  control,  and 
underwater  ship  husbandry. 

MDSU  One  and  MDSU  Two’s  mission  is  to  provide  a  combat-ready,  deployable 
detachment  to  conduct  harbor  clearance,  salvage,  underwater  search  and  recovery,  and 
underwater  emergency  repairs.  They  are  equipped  with  diving  and  salvage  equipment 
that  is  air-mobile  and  scalable  to  mission  objectives.  The  detachment  can  be  as  small  as 
five  divers  for  small  operations,  such  as  side  scan  sonar  search  operations,  to  larger 
groups  for  larger  salvage  operations.  Both  MDSUs  are  components  of  the  Naval 
Expeditionary  Combat  Command.  For  the  purposes  of  this  paper,  the  mission  describes 
only  aspects  of  diving,  salvage,  and  towing  as  part  of  the  triad  discussed  [21]. 

The  mission  of  Military  Sealift  Command  (MSC)  is  to  provide  combat  logistics  to 
sustain  U.S.  forces  worldwide,  during  peacetime  and  in  war,  for  as  long  as  operational 
requirements  dictate.  Administratively,  MSC  is  a  Navy  echelon  III  command  under  U.S. 
Fleet  Forces  (USFF),  providing  more  than  40  govemment-owned/govemment-operated 
ships.  Operationally,  MSC  is  the  Navy  Component  Commander  to  the  U.S. 
Transportation  Command  (USTRANSCOM),  supporting  mission  objectives  through 
Sealift  Logistics  Commanders  (SEALOGS).  An  Echelon  IV  command  named  Military 
Sealift  Fleet  Support  Command  (MSFSC)  was  formed  in  October  2006  to  man,  train, 
equip,  and  maintain  Government-owned  and  Government  -operated  (GO-GO)  ships.  The 
T-ARS  and  T-ATF  ships  are  a  part  of  the  Type  Command  (TYCOM)  under  the  MSFSC 
and  are  manned  by  civilian  merchant  mariners  (CIVMARS).  Performing  these  type- 
commander  responsibilities  makes  MSFSC  the  only  subordinate  command  under  MSC 
with  global  responsibilities  [22], 
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c. 


SALVAGE  AND  TOWING  SHIP  HISTORY 


“Ships  are  built  for  a  variety  of  purposes,  but  all  must  meet  certain  fundamental 
requirements.  They  must  have  reserve  buoyancy  to  enable  them  to  carry  their  designed 
loads  and  resist  damage,  stability  to  resist  environmental  forces  or  damage,  and  strength 
to  withstand  the  stresses  imposed  on  their  structure  by  their  own  weight,  cargo  stores,  and 
the  sea”  [23],  U.S.  Navy  Salvage  and  Towing  ships  are  required  to  be  robust  enough  to 
endure  the  stress  of: 

•  combat  salvage 

•  rescue  towing 

•  fire  fighting 

•  emergent  repair 

•  ocean  towing 

•  heavy  lift 


Figure  10.  ATF  Navajo  Class.  From[24] 

Fleet  tugs  are  used  to  tow  ships,  barges  and  targets  for  gunnery  exercises.  They 
are  also  used  as  platforms  for  salvage  and  diving  work,  as  participants  in  naval  exercises, 
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to  conduct  search  and  rescue  missions,  to  aid  in  the  cleanup  of  oil  spills  and  ocean 
accidents,  and  to  provide  firefighting  assistance.  The  Navy  designed  the  first  seagoing 
‘tug,’  the  NAVAJO  (ATF-64)  class  in  1939,  to  support  logistic  requirements  for  World 
War  II.  The  German  U-boats  were  inflicting  damage  to  both  military  and  commercial 
vessels  to  the  point  of  clogging  major  waterways  in  Europe.  The  vessels  served  the  Navy 
well  for  over  fifty  years.  Their  long-range  seaworthiness  made  them  valued  as  ocean¬ 
going  tugs  and  for  combat  towing  operations.  During  combat  operations,  the  ATF  class 
ships  would  also  perform  some  firefighting  and  salvage  assistance.  Wooden-hulled 
Rescue  vessels  (ATR  class)  were  utilized  in  submarine-infested  waters  for  firefighting 
support  and  light  towing,  but  did  not  have  an  ocean-going  towing  capability.  The  steel¬ 
hulled  BOLSTER  (ARS-38)  class  vessels  were  designed  as  salvage  ships  but 
incorporated  a  powered  reel  for  towing,  which  made  them  interchangeable  with  the  ATF 
for  ocean-going  towing.  This  made  for  an  excellent  design  and  served  the  U.S.  Navy 
well  until  the  mid  1990s  [25].  The  newer  SAFEGUARD  (ARS-50)  class  salvage  ships 
were  an  improved  design  to  accommodate  heavier  salvage  work  and  increased  bollard 
pull. 


Figure  11.  ATR-52  -  Rescue  Tug  From[24] 


Although  the  Navy  recognizes  several  types  of  towing,  the  purpose  of  this  study  is 


limited  to  ocean  towing,  rescue  towing,  and  salvage  towing.  Ocean  towing  is  defined  as 
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point-to-point  (from  one  harbor  to  another)  towing  with  no  refuge  enroute.  This  includes 
the  safe  towing  of  defueled,  nuclear-powered  ships.  Rescue  towing  is  the  saving  of  a 
stricken  or  inoperable  ship  at  sea  and  towing  it  to  a  safe  harbor.  Salvage  towing  involves 
the  immediate  towing  of  a  vessel  after  a  salvage  operation.  Combat  Salvage  and  towing 
missions  involve  service  in  hostile  areas  where  vessels  are  damaged,  afire,  disabled,  or 
stranded  due  to  enemy  fire  [26]. 


Figure  12.  ARS-38  Bolster  Class  From  [24] 


Salvage  ships  can  perform  as  towing  platforms,  but  their  primary  missions  are  to 
perform  combat  salvage,  emergency  repair,  and  firefighting.  Many  of  the  attributes  that 
make  salvage  ships  good  salvage  and  towing  platforms  also  make  them  good  platforms 
for  performing  engineering  operations.  Specifically,  tugs  that  can  perform  open  ocean 
tows  are  often  equipped  with  heavy  lift  cranes,  have  large  expanses  of  deck  area  for 
temporary  installation  of  specialized  equipment,  and  are  designed  to  keep  station  or  moor 
over  a  site  of  interest  [27],  An  emerging  capability  is  a  Vessel  Of  Opportunity  (VOO)  for 
Remote  Operating  Vehicles  (ROV)  and  Side  Scan  Sonar  systems  to  explore  the  ocean’s 
depths  for  search  and  recovery  operations. 
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D.  TOWING  AND  SALVAGE  TODAY 


Figure  13.  T-ATF  Powhatan  class  From  [24] 


Presently,  the  MSFSC  has  a  force  of  four  T-ATF- 166  (Powhatan  class)  ocean- 
towing  ships  and  four  T-ARS-50  (Safeguard  class)  Salvage  ships.  The  vessels  are 
defined  as  Government-Owned  Contractor-Operated  (GO-CO)  and  are  located 
throughout  the  world.  Both  ship  characteristics  are  located  in  Table  3  (unknown  data 
marked  as  UNK). 

Both  classes  of  ships  can  perform  ocean-going  towing  services  such  as  tow  ships, 
barges  and  targets  for  gunnery  exercises.  The  ARS  class  towing  system  incorporates  a 
double  drum,  automatic  towing  winch  and  traction  winch.  The  two  main  drums  hold 
3,000  feet  of  2.25-inch  wire  rope.  The  deck  area  aft  has  a  cap  rail  and  two  tow  bows  can 
be  installed.  Retractable  stem  and  side  tow  rollers  are  also  available  on  the  ARS  class. 
The  bollard  pull  of  65.5  tons  is  adequate  to  pull  a  NIMITZ  class  aircraft  carrier  [27].  The 
primary  mission  for  the  ATF  class  is  towing;  it  has  a  bollard  pull  of  75  tons.  Its  towing 
system  is  a  SMATCO  holding  2,500  feet  of  2.25-inch  wire  rope.  It  also  has  a  15-inch 
Lake  Shore  Inc.  traction  winch  [28], 
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ARS-50 

class 

ATF-166 

class 

Hull 

Length,  Overall  (ft) 

255 

226 

Breadth,  molded  maximum  (ft) 

52 

42 

Depth,  molded,  at  side  to  main  deck  amidships  (ft) 

23 

UNK 

Height,  maximum  to  DWL  (ft) 

115 

UNK 

Displacement,  light  (approximate  without  margin)  (Tons) 

2160 

1387 

Displacement,  full  load  (approximate  without  margin) 
(Tons) 

3282 

2260 

Draft,  full  load  (ft) 

17.5 

15.5 

Machinery 

Number  of  propulsion  shafts 

2 

2 

Design  full  power  ahead,  shaft  horsepower  (hp) 

4,200 

7,200 

Endurance  at  8  knots  (ARS,13  knots  (ATF)  )(in  miles) 

8000 

10000 

Speed,  100  percent  power,  free  route  (knots) 

14.5 

14.5 

Bowthruster  (hp) 

500 

300 

Number  of  diesel  generators,  60  Hz  750kW,  45  Ov,  3phase 

3 

UNK 

Accommodations 

Ship’s  crew 

26  civ.,  4 
mil. 

16  civ.,  4 
mil. 

Transients 

Provisions  and  Stores 

Dry  (days) 

75 

UNK 

Chilled  (days) 

30 

UNK 

Frozen  (days) 

75 

UNK 

Liquid  Load 

Fuel  (gallons) 

123,492 

UNK 

Potable  water  (gallons) 

30,745 

UNK 

Ballast  (gallons) 

87,847 

UNK 

Bollard  pull  (tons-force) 

65.5 

75 

Table  3.  Ships  characteristics  From[26],[28] 
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Figure  14.  T-ARS  Safeguard  class.  From  [24] 


The  main  mission  of  the  ARS  class  is  diving  and  salvage.  The  diver’s  life- 
support  system  is  integrated  into  the  ship  and  is  capable  of  supporting  up  to  six  divers 
through  its  consoles.  It  also  has  a  fixed  decompression  chamber.  The  system  has  primary 
300psi  medium  pressure  air  and  3,000psi  high  pressure  secondary  air.  At  the  forward 
part  of  the  fantail,  there  are  diver’s  davits  for  lowering  and  raising  a  diver’s  stage. 
Additionally,  a  300psi  tunneling  manifold  is  available  on  the  port  side  of  the  fantail  for 
tunneling  under  large  objects  on  the  ocean  floor  [26].  A  detachment  of  MDSU  sailors 
augment  the  crew  for  deployment  and  emergent  salvage  operations.  MDSU  sailors  also 
supplement  the  ATF  MSFSC  crew  for  missions.  The  ATF  class  ship  does  not  have  any 
diver’s  life-support  systems  integrated;  it  must  be  brought  onboard  by  the  MDSU 
detachment.  Although  MDSU  detachments  have  been  embarking  ARS  class  ships  for 
only  the  past  two  years,  they  have  successfully  completed  missions  onboard  ATF  classes 
for  more  than  a  decade. 

Off-ship  firefighting  can  be  accomplished  by  both  classes.  Both  classes  have 
three  fire  monitors  and  are  capable  to  dispense  (ARS  -  lOOOgpm,  ATF  -  2200gpm) 
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seawater  or  aqueous  film- forming  foam  (AFFF)  [26]  [28].  Fire  hoses  can  also  be 
attached  to  manifolds  when  coming  alongside  the  vessel  on  fire. 

For  heavy  lifts  of  sunken  material,  the  T-ARS  can  exert  300  tons  of  lifting  force 
via  stem  and  bow  rollers  [26],  The  T-ATF  has  a  maximum  lift  of  100  tons  over  stem 
rollers  [28].  The  aft  boom  on  the  T-ARS  forms  a  compensating  system  with  its  vang  and 
topping  tackle,  which  allows  for  simultaneous  control  of  slewing  and  topping,  ensuring 
load  stability  up  to  40  tons.  The  forward  boom  on  the  T-ARS  also  has  this  capability  up 
to  7.5  tons  when  rigged  in  the  aft  position  [26],  The  T-ATF  vessel  is  equipped  with  a  10- 
ton  capacity  crane  [29].  The  T-ARS  has  an  installed  de-beaching  capability.  A  pull  of 
160  tons  can  be  exerted  on  a  stranded  vessel  utilizing  tow  wires,  propulsion  engines,  and 
two  legs  of  beach  gear.  Additionally,  a  retraction  force  of  up  to  360  tons  can  be  rigged 
with  six  legs  of  de-beaching  gear  [26], 

E.  MOTIVATION  FOR  TOWING  AND  SALVAGE  MODULE 

Both  classes  are  coming  to  the  end  of  their  service  life  of  40  years;  to  allow  for 
the  budgeting  process,  plans  to  recapitalize  the  MSFSC  fleet  of  ocean-going  tugs  and 
salvage  ships  must  begin  soon.  The  course  of  action  described  in  this  thesis  is  to 
architect  the  capabilities  (and  future  capabilities)  of  these  vessels  into  a  single  hull 
design.  This  course  of  action  is  to  save  Ship  New  Constmction  (SCN)  funds  and  have 
the  capabilities  of  both  vessels  on  one  platform.  Although  many  factions  of  architecture 
(such  as  hull,  propulsion,  electrical  loading,  etc)  for  ship  design  are  needed,  this  thesis 
will  cover  only  those  that  are  in  the  view  of  achieving  the  capabilities  for  towing  and 
salvage. 

The  USFF  analysis  suggested  the  combined  warfighting  and  peacetime 
requirements  of  nine  vessels  to  accomplish  both  towing  and  salvage  tasks;  an  acceptable 
risk  would  be  eight.  CNA  analysis  suggests  seven  ships,  augmenting  with  contracted 
commercial  tows  as  needed.  Currently,  the  warfighting  requirement  dominates  peacetime 
demand  [30], 

To  accommodate  a  shipbuilding  plan  for  eight  ships  of  a  single  hull  type,  the 
assumption  is  made  to  establish  a  timeline  to  begin  lead  ship  construction  in  FY16.  The 
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notion  is  to  replace  the  legacy  ships  (both  ARS  and  ATF)  near  the  end  of  their  service  life 
(ESL)  of  40  years.  The  breakdown  of  replacing  these  ships  by  hull  number  is  shown  in 
Table  4  Pre-construction  activities  should  begin  in  FY10,  starting  with  establishing  an 
Integrated  Product  Team  (IPT),  an  acquisition  strategy,  and  formalizing  ship 
requirements.  In  following  years,  a  notional  timeline  is  as  follows  [30]  : 

•  FY12  -  Perform  concept  and  preliminary  design  and  program 

documentation 

•  FY13  -  Develop  notional  design,  cost  estimates,  and  contract 

documentation;  release  RFP 

•  FY14  -  Award  competitive  Phase  I  design  contracts  and  oversee  design 
phase 

•  FY15  -  Complete  design  phase;  execute  source  selection  for  Detail  Design 
and  Construction  phase 

•  FY16  -  Award  contract  for  Phase  II  Detail  Design  &  Construction 
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RECAPITALIZATION  OF  SHIPS  IN  OUTYEARS 

FY14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

BATTLEFORC 

INVENTORY 

ATF 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

ARS 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

PROCUREMENTS 

ATF/ARS 

1 

1 

1 

1 

1 

1 

1 

1 

DELIVERIES 

ATF/ARS 

1 

1 

1 

1 

1 

1 

1 

1 

RETIREMENTS 

ATF 

-1 

-1 

-1 

-1 

ARS 

-1 

-1 

-1 

-1 

SHIP  AGE  BY  YEAR  AT  RETIREMENT 

FY14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

T-ATF 
(ESL  =  40 
YRS) 

HULL# 

CATAWBA 

168 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

NAVAJO 

169 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

SIOUX 

171 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

APACHE 

172 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

T-ARS 
(ESL  =  40 
YRS) 

HULL# 

SAFEGUARD 

50 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

GRASP 

51 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

SALVOR 

52 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

GRAPPLE 

53 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

Table  4. 


Recapitalization  of 


-ATF/ARS.  Modified  From  [ 


0] 


F.  SUMMARY 

Recapitalizing  the  Navy’s  fleet  with  a  single  hull  design  requires  an  architecting 
approach  that  is  mapped  to  the  capabilities  of  the  vessels  already  in  service,  along  with 
future  capabilities  anticipated  by  the  salvage  and  towing  community.  The  architecture 
high-level  system  is  already  defined  as  being  a  ship  with  mission  needs  and  stakeholder 
concerns.  The  architecting  process  synthesizes  a  design  for  acquisition  of  this  new  ship 
class.  The  explanation  of  the  architecting  process,  and  applying  it  with  an  architecting 
tool,  is  described  in  the  next  chapter. 
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IV.  THE  ARCHITECTING  PROCESS  AND  APPLICATION 


Architecture  is  a  science,  arising  out  of  many  other  sciences,  and  adorned 
with  much  and  varied  learning:  by  the  help  of  which  a  judgment  is  formed 
of  those  works  which  are  the  result  of  other  arts. 

—  Vitruvius 


A.  INTRODUCTION 

There  is  a  great  need  to  describe  a  process  to  ensure  that  the  architecture,  the 
arrangement  of  elements  and  their  relationships,  is  well-defined  and  addresses  the  needs 
of  the  stakeholders  [19].  The  intention  of  this  chapter  is  to  define  a  systems  architecting 
process,  and  to  illustrate  the  manner  of  how  a  legacy  system  could  be  architected  in  the 
context  of  a  SoS  from  a  given  set  of  stakeholder  information  —  in  this  case,  from  the 
U.S.  Navy  Diving  and  Salvage  community. 

B.  ARCHITECTURE  METHODOLOGY 

The  intention  of  the  current  JCIDS  process  is  for  the  architecting  process  to  begin 
with  a  top-down  approach,  starting  with  a  capability  need.  Currently,  the  DODAF 
defines  an  outline  of  the  architecture  product  development  through  a  high-level,  six-step 
process.  The  first  five  steps  consists  of  defining  the  purpose,  defining  a  scope, 
identifying  key  architecture  characteristics,  determining  products  to  build,  and  then 
building  the  crucial  products.  The  sixth  step  is  not  covered  in  either  volume  of  the 
DODAF,  but  it  states  the  architecture  is  to  be  used  for  its  intended  purpose.  No  specific 
description  of  a  methodology  is  included  (such  as  object-oriented  or  structured  analysis), 
or  notation  to  be  used  (such  as  UML  or  SySML).  DODAF  VOL  II:  Products 
Descriptions  provides  UML  diagrams  as  an  example  of  a  general  purpose  modeling 
language  for  software  systems.  Figure  15  shows  the  six-step  process,  for  simplification 
without  the  feedback  loops  [19], 
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Figure  15.  DODAF  Six  Step  Process  for  Building  an  Architecture  Description 

From[19] 

These  products  are  mapped  as  part  of  the  process  using  SySML  shown  in  Figure 
16.  The  process  loosely  joins  the  diagrams  and  aids  in  verification  of  the  system.  Table 
5  shows  the  actual  products  mapped;  note  that  the  blank  spaces  imply  no  mapping 
between  the  entities  [31]. 
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SoKADP 

DoDAF  Product 

|  SfysML  Diagrams  j 
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Structure 

Behavior 
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Requirement 

Diagram 

Block 

Diagram 

Is  arametnc 
Diagram 

Activity 

Digram 

3  equence 
Diagram 

Use 

Cases 

Modektg 

& 
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n 

Contest 

L  .li^; 

SoS  Problem 

Textual  information  (not  AY- 1] 

Needs  Analysis 

Analyze  SoS  Needs 

Textual  information  (part  of  AV-  Ij 

Develop  MGEs 

V 

Mission  Analysis 

AV-l.OV-1 

Determine  Threats 

OY-1  (High-level  Operational  Concept  Graphic) 
AY-1  (Overview  and  Summary  Information ) 

V 

Define  Scenarios 

V 

V 

Define  Missions 

V 

V 

Re  qun  L'mi'iib;  Analysis 

OVA  OV-5,  SV4,  SV-5 

Perform  Operational  Requirements  Analysis 

SV4  (Systems  Functionably  Description) 

V 

P  storm  Functional  Analysis 

SV4  (Systems  Functicnatity  Desorption) 

V 

P  erfbrm  Non-functional  Analysis 

■v 

Flowdown  Requirements 

SV4  (Systems  Functionality  Description) 

V 

V 

Develop  MOP- 

Perform  Thread  Analysis  with  Data  & 
Messages 

OY-Sc  (Operational  Event  Trace  Description) 

V 

V 

SoS  Arc  lute  r  hue  Alrtiii  mlivts 

OV-3 

Define  SoS  Force  Composition  Options 

V 

V 

Identify  Critical  Elements 

Identify  Easting  Systems 

Postulate  Future  Systems 

P  erfbrm  Functional  Embedding 

SV  (Systems  Interface) 

Define  SoS  Comm.  Structures 

V 

V 

Define  SoS  C2  Structures 

OY-4  (Orgambona]  Rehfcontihips  Chart) 

V 

V 

Define  SoS  Architecture  Options 

SV-1  (Systems  Interface) 

V 

y 

Define  CONORS 

Develop  concepts  cooperations 

OY-5  (Operational  Activity  Model) 

V 

V 

Develop  Internal  Threads  with  Data  & 
Messages 

SY-1  (Systems  Interface) 

V 

V 

Cost  mi  Risk  Analysis 

Model  Cost 

Identify  Risk 

SoS  Arclntectme  Finikin* 

Perform  M&S 

V 

V 

Conduct  Performance  Analysis 

V 

V 

Select  SoS 

V 

i 

Rank  SoS  Architecture  Alternatives 

V 

V 

Table  5.  Mapping  between  SoSADP,  DODAF,  and  SySML  Diagrams. 

From[31] 


Architecture  is  a  key  aspect  the  systems  engineering  process,  as  the  architecture  is 
the  first  tangible  part  of  the  design.  Systems  architecting,  along  with  systems 
engineering,  takes  high-level,  capability-based  need  identification  to  define  and  analyze 
capabilities,  activities,  mission  tasks,  requirements,  functions,  synthesis  of  abstract 
concepts,  and  systems  analysis  of  alternatives  to  their  eventual  instantiation  as  a  physical 
system.  The  architecting  methodology  is  part  of  a  disciplined  process  that  creates  and 
documents  architectures,  and  uses  them  as  an  integral  part  of  the  overall  systems 
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development  process.  It  provides  the  framework  for  the  description  of  the  operational 
usage  of  the  system,  which  in  turn  provides  a  starting  point  for  the  systems  engineering 
product  development.  To  define  this  architecture-based  systems  engineering  process,  the 
architecting  process  is  first  associated  with  the  steps  of  classical  systems  engineering, 
especially  the  early  phases,  as  shown  in  Table  6  [9]. 


Requirements 
Definition  Process 


Problem  Definition  and  Needs 
Identification 


Advance  System  Planning 


System  Feasibility  Analysis 


System  Operational  Requirements 
Maintenance  &  Support  Concept 
Technical  Performance  Parameters 


Functional  Analysis  &  Allocation 
System  Trade  Off  Analysis 


System  Specification 


Conceptual  Design  Review 


Table  6. 


Early  Stage  Systems  Engineering  Steps,  Based  on  [32] 


Requirements  analysis,  functional  analysis,  and  allocation  are  accomplished  to 
achieve  specific  capabilities  based  on  needs.  The  resulting  functional  architecture  should 
be  a  fairly  stable  view  of  the  system.  Design  synthesis  is  the  creation  of  sets  of 
components  as  integrated  concepts  and  their  respective  mapping  from  the  functional 
architecture.  System  analysis  is  then  performed  to  determine  how  to  use  the  trade  space 
to  balance  between  alternative  concept  designs  combinations  of  legacy  and  innovative 
new  components  to  create  an  elegant,  enduring,  and  useful  physical  architecture.  System 
specifications  are  then  used  as  the  basis  for  the  next  major  phase,  the  realization  of  the 
system  in  final  form.  Next,  the  process  is  expanded  and  categorized  into  a  series  of 
aspects  associated  with  each  phase:  architecting  and  then  engineering,  as  seen  in  Table  7. 
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Systems 

Architecting 

Operational  Need 

Identify  pressing  need  or  emerging  opportunity  as  a 
capability  gap 

Develop  concept  of  operations  including  existing  and 
planned  systems 

Define  operational  activities 

Develop  operational  nodes  and  elements 

Develop  operational  scenarios 

Define  operational  requirements 

Architecture  Synthesis 

Develop  activity  models 

Create  functional  architecture  (hierarchy  and  flow) 

Define  and  characterize  functional  behavior 

Run  simulations 

Characterize  architecture  specifications 

Systems 

Engineering 

Requirements  Definition  & 
Analysis 

Develop  “engineerable”  requirement  specifications 

Functional  Analysis  of 

Functional  and  Non-Functional 
Requirements  &  Allocation  to 
Derived  Elements 

Create  derived  functional  architecture  (hierarchy  and 
flow) 

Derive  functional  and  non-functional  requirements 

Develop  system  elements 

Allocate  functions 

Model  and  simulate  behaviors 

Design  Synthesis 

Create  physical  architecture  (structure) 

Model  and  simulate  feasibility  “physics” 

Trade  off  alternatives 

Select  “best”  from  Pareto  optimal  set 

Define  system/subsystem  specifications 

Test  and  Evaluation 

Continuously  validate  development 

Table  7.  Systems  Architecting  &  Engineering  Activities  High  Level  Outline. 

From[9] 


The  use  of  consistent  terminology  to  describe  the  elements  in  an  architecture  is 
important.  The  ASN  (RDA)  Chief  Systems  Engineer  has  addressed  the  existing  situation 
of  non-specific,  architecting-related  terminology  by  standardizing  the  definition  of 
Architectural  Elements  within  a  Naval  Architectural  Repository  System  (NARS).  Each 
architecture  should  be  created  with  common  terms,  thereby  forming  interoperability 
between  them  even  if  the  architecting  tools  are  different.  Table  8  lists  the  architecture 
elements  cross-referenced  the  different  views  as  required  in  the  CJCSM  3170.  Further 
explanation  of  each  architecture  element  is  defined  by  the  ASN  (RDA)  is  in  Table  9. 
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Designated  by  the  DODAF  as  Critical 


ARCHITECTURE  ELEMENTS 

rw\ 

Derational  View  (OV)  | 

|  System  View  (SV)  | 
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• 

•  (c) 
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• 

§ 
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• 
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t 

t 

• 

•  (b,c) 

• 
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• 

t 

• 

• 

t 

• 

• 

§ 

t 

Systems  Nodes*0 
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• 

§ 

Systems*0 

• 

• 

• 

t 

§ 

t 

• 

•  (a,b,c) 

System  Functions*0 
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• 

§ 

•  (a,b,c) 

Triggers/Events*0 

• 

•  (b.c) 

•  (b.c) 

Performance  Parameters*0 

• 

• 

Technical  Standards*0 

• 

• 

• 

Technology  Areas*0 

• 

t 

• 

Mission  Capabilities*0 

” 

1 

1 

_ 

1 

I 

| 

1 

I 

Z 

1 

1 

•  =  Element  Required  by  DODAF  1.5 

(1)  Standardized  in  the  Naval  Architecture  Elements  Reference  Guide,  https://ncee.navy.mil/ 

(2)  Required  by  DODI  4630.8,  CJCSM  3170.01C  or  CJCSI  6212.01D  (excluding  OV-6a/b) 


Table  8.  Architecture  Usage  Products.  From  [33] 
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Architecture  Element 

Definition 

System  Functions 

Data  transform  supporting  automation  of  activities  or 
information  element  exchanges 

Operational  Tasks 

Discrete  unit  of  work  enabling  a  mission  to  be 
accomplished 

Technical  Standards 

Provides  for  a  common  set  of  interface  and  technical 
build-to  parameters 

Operational  Activities 

Action  or  process  performed  to  accomplish  an 

Operational  Task 

Information  Elements 

Identification  of  information  to  be  passed  between  and 
among  forces,  organizations,  or  administrative  structures 
supporting  ongoing  activities 

Operational  Nodes 

Represent  organizations,  organization  types,  and 
occupational  specialties. 

System  Nodes 

A  node  with  the  identification  and  allocation  of  resources 
(e.g.,  platforms,  units,  facilities,  and  locations)  required 
to  implement  specific  roles  and  missions. 

Systems 

Organized  assembly  of  resources  and  procedures  united 
and  regulated  by  interaction  or  interdependence  to 
accomplish  a  set  of  specific  requirements 

Mission  Capabilities 

Possession  of  the  means  to  use  military  force  to  achieve 
an  intended  effect  with  the  battle  space  that  can  be 
measured 

Triggers/Events 

Specifies  the  cause  that  initiates  a  series  of  actions 

Performance  Parameters 

Common  set  of  performance  parameters  and  their  metric 
units 

Technology  Areas 

Description  of  emerging  technologies  providing  an 
operational  capability.  (Based  on  current  state-of-the-art 
technologies  and  expected  improvements.) 

Table  9.  Architecture  Elements.  From  [34] 


The  definition  of  element  relationships  is  key  to  defining  the  architecture.  Table 
10  shows  the  correct  attribute  needed  to  connect  element  classes  to  each  other  in  CORE. 
The  column  of  notes  will  help  guide  the  architect  to  which  attribute  is  needed.  An 
element  can  use  various  attributes,  but  CORE  is  designed  to  allow  only  the  correct  target 
class  to  be  selected,  assisting  in  keeping  the  architecture  in  its  proper  organization. 
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Element 

Class 

Attribute 

Targeted 

Class 

Note 

Highest  Level  Objective 

Architecture 

achieves 

Capability 

Highest  level  accomplishment 
objective 

Who  Said  What  We  Need? 

Documents 

document 

Guidance 

Top  level  authority  describes  a  need 
in  terms  of  capabilities. 

Operational  Domain 

Guidance 

defines 

Capability 

Capability 

achieved  by 

Operational 

Activity 

Operational  Activity  stated  as 
operational  scenario.  Context  scoped 
by  and  described  based  on  CONOPS. 

Operational 

Activity 

achieves 

Mission 

Mission 

achieved  by 

Operational 

Task 

Operational  Tasks  based  on  e.g. 

UJTL;  Mission  based  on  e.g.  METL 

Operational  Task 

results  in 

Requirement 

Operational  Task  results  in 

Operational  Requirement,  which  ties 
Operational  Domain  to  System 

Domain 

Operational 

Node 

assigned  to 

Organization 

Operational 

Node 

performs 

Operational 

Activity 

System  Domain 

Operational  Task 

implemented 

by 

Function 

For  “Top  Down”  development 
situation  where  capabilities  stated 
first,  as  in  unprecedented  systems, 
function  derived  from  tasks  that  are 
used  to  accomplish  mission. 

Ties  Operational  Domain  to  System 
Domain. 
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Element 

Class 

Attribute 

Targeted 

Class 

Note 

Function 

based  on 

Requirement 

For  unprecedented  systems, 
Operational  Requirements  are 
determined  first.  At  highest  level, 
Operational  Requirements  lead  to 
System  Requirements,  both 
functional  and  non-functional,  which 
provides  the  basis  for  Function.  For 
“Middle  Out”  or  “Bottom  Up” 
development  situation,  where 
requirements  stated  explicitly  in 
Guidance,  or  legacy  systems  exist, 
system  requirements  may  already 
available,  and  can  be  input  directly 
from  Guidance 

Function 

performed  by 

Component 

Component  is  part  of  physical  system 
solution. 

Other  Element  Relationships 

Component 

consumes 

Resource 

System  resource  (fuel,  data  storage, 
etc ) 

Function 

triggered  by 

Item 

Items  are  what  is  I/O  through  links 

Requirement 

specifies 

Component 

Information  for  engineers  to  use  for 
system  design. 

Component 

implements 

Operational 

Node 

Ties  System  Domain  to  Operational 
Domain. 

Table  10.  Architecting  Relationships. 


C.  ORGANIZATION  OF  DODAF  FRAMEWORK  PRODUCTS 

The  DoD  Systems  Acquisition  process  requires  documents  such  as  the  ICD, 
CDD,  CPD,  and  CRD,  which  use  architectural  products  to  support  decision  making. 
These  products  are  created  in  an  iterative  manner,  and  the  level  of  detail  increases 
throughout  the  development  life  cycle.  For  instance,  the  first  generation  of  models 
consists  of  the  highest  level  of  the  SoS.  As  the  process  continues,  more  detailed 
graphical  textual  products  are  generated.  Figure  17  shows  an  example  of  some  products 
produced  and  how  they  align  to  the  different  views  supported.  As  the  architecture  is 
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developed,  elements  must  be  able  to  map  back  to  the  products  throughout  each  cycle  or 
iteration  of  analysis  and  decomposition.  A  tool  to  assist  in  creating  the  element 
relationships,  CORE,  has  been  designed  by  Vitech  Corporation,  an  industry  provider  of 
Model  Based  Systems  Engineering  (MBSE)  tools  and  solutions. 


Basic  Principles 

Graphic,  Textual,  and  Tabular  Products 

(With  Associated  Data) 


System  Functionality 
Description  (5V-4} 


Systems  Functionality 
Sequence  and  Timing 
Description  jSV-10  a^hic) 


System  -  System 

Matrix.  4SV-3]  Sterns  Evolution- 
Description  (SV-8J 


Activity  to  System 
Function  (SV-5)  Systems  Interface 
Description  (SV-1) 


Systems  Data  Exchange 
Matrix  (SV-G) 


Systems  Communications 
- Description  (SV-2) 


Systems  Performance  h- 
Parameters  Matrix  (SY"7' T 


Systems  Technology 
Forecast  (SV-&) 


Operational  Concept 
Description  (OV-1) 


eET"^ 

Organizational 
Relationships  Chart 
jOV-4) 


Activity  Model  (OV5) 


Technical 
Architecture 
Profile  (TV-1) 


Node  Connectivity 
Description  (OV-2) 


Logical  Data 
Model  (OV-7J 


Information  Exchange 
Matrix  (OV-3) 


Standards  Technology 
Forecast  jSV-9) 


Operational  Activity 
Sequence  and  Timing 
Description  (OV-6  aJttfc) 
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Figure  17.  Illustration  of  Products  to  each  view.  From  [34] 

D.  CORE  ARCHITECTURE  DEVELOPMENT 

CORE  focuses  on  an  architecture  synthesis  centric  approach  rather  than  a  view  or 
document  centric  approach.  This  provides  traceability  from  capability  through 
requirements  and  analysis  to  testing.  The  CORE  software  suite  was  designed  by  systems 
engineers  to  satisfy  diverse  civilian  and  military  customer  (or  stakeholder)  needs. 
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CORE  is  built  around  a  central  integrated  design  repository.  It  includes  a  comprehensive 
behavior  modeling  notation  to  understand  the  dynamics  of  a  design.  CORE  also  has  the 
ability  to  perform  product  simulation  [35], 

CORE  is  a  MBSE  tool  designed  to  integrate  architectural  and  engineering 
activities  while  developing  operational  and  system  models.  Documentation,  such  as  the 
DODAF  views,  are  derived  from  the  basis  architecture  produced.  The  architecture  is 
created  based  on  a  DODAF  schema,  Figure  18,  which  explicitly  shows  the  attributes  and 
relationships  established.  The  schema  has  two  distinct  domains;  Operational  and  System. 
The  Operational  Architecture  Domain  captures  originating  concepts,  capabilities,  and 
supporting  operational  analysis  to  exploit,  whereas  the  System  Architecture  Domain 
expresses  the  requirements,  functions,  and  components  comprising  the  physical  design 
[36]. 
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E. 


CORE’S  OPERATIONAL  AND  SYSTEM  ARCHITECTURAL  DOMAIN 
RELATIONSHIPS 


VITECH  has  implemented  the  architecture  elements  in  a  DODAF  vl.5  schema  to 
populate  a  database  of  element  classes  to  enable  the  architect  to  define  relationships,  list  a 
description,  and  show  hierarchies  and  various  other  characteristics.  The  two  domains, 
Operational  and  System,  are  portioned  such  that  the  architecture  is  defined  considering 
two  views  that  are  linked.  In  CORE,  architecture  is  composed  of  Operational  Nodes  and 
Components.  Operational  Nodes  identify  the  operational  environment  or  external  aspects 
of  the  operational  domain  and  components  are  the  physical  system  elements  that  map  to 
the  operational  nodes.  The  Operational  Nodes  are  implemented  by  the  components,  and, 
conversely,  the  components  implement  the  operational  nodes.  In  addition  to  this 
mapping  between  operational  and  system  domains,  there  are  three  other  major  mappings, 
summarized  in  Table  11  [36], 


Operational  Node 

Component 

Need  Line 

Link 

Operational  Information 

Item 

Operational  Activity 

Function 

Table  11.  Operational  to  Systems  Traceability  Based  on 
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F.  T-ARS(X)  ARCHITECTURE  DEVELOPMENT  EXAMPLE 

Just  as  in  the  case  for  general  architectures,  there  is  no  particular  beginning  entry 

point  necessary  to  start  the  architecting  process.  The  architecting  process  for  this  example 

has  a  large  portion  of  legacy  architecture  that  essentially  acts  as  context  for  the 

architecting  of  the  desired  new  towing  capability.  The  process  for  systems  architecture 

development  then  is  initiated  using  a  “Middle  Out”  method,  as  some  legacy  system 

characteristics  are  known.  In  a  “Middle  Out”  start,  the  architecture  model  is  synthesized 

beginning  with  the  legacy  system’s  known  characteristics  and  requirements.  The  element 

relationships  form  the  basis  of  the  architecture  structure,  and,  since  their  formation  can  be 
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accomplished  in  just  about  any  order,  this  still  results  in  a  complete  set  of  element 
relationships.  In  this  case  of  “Middle  Out,”  as  the  requirements  are  iterated,  mapping 
back  to  capabilities,  capability  gaps  can  be  exploited  to  resolve  legacy  system  faults  as 
the  architecture  becomes  more  fully  developed.  The  top-down  aspect  still  must  exist  as 
mapped  to  the  JCA  and  ROC,  as  needed,  since  the  highest  level  context  must  still  be 
included.  The  system  architecture  model  has  the  opportunity  to  expand  to  accept  new 
capabilities,  should  they  arise,  upon  further  study.  Each  iteration  will  bring  the  system 
closer  to  a  design  to  carry  on  to  the  solution  domain  for  further  systems  engineering.  The 
documentation  for  the  operational  capability  needs  for  this  does  not  exist  as  a  set  of 
JCIDS  products.  Nonetheless,  the  architecture  products  must  be  developed.  The  starting 
point  for  a  system  acquisition,  once  the  JCIDS  process  is  complete,  is  the  ICD  that  will 
be  used  as  a  starting  point  for  this  example.  Mandatory  Appendices  for  an  Initial 
Capabilities  Document  (ICD)  [4]  require  only  one  integrated  architecture  product  —  the 
OV-1.  This  view  illustrates  the  intended  use  of  the  architecture  for  a  quick,  high-level 
description.  The  value  added  is  a  summary  level  description  of  organizations  and/or 
roles,  mission,  and  context  for  the  architecture.  It  will  highlight  main  operational  nodes 
and  provide  a  description  between  the  architecture,  the  actors,  and  the  environment. 
CORE  does  not  provide  a  function  to  produce  an  OV-1;  instead,  a  textual  description  is 
imported  into  the  program  for  linking  products.  Figure  19  is  an  example  of  an  OV-1  for 
the  T-ARS(X)  developed  in  Microsoft  PowerPoint.  CORE  is  utilized  to  develop 
examples  of  Operational  and  System  Views  mandatory  for  the  Capability  Development 
Document  (CDD).  The  OV-1  in  Figure  19  is  translated  into  CORE  to  begin  the 
architecting  process. 
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T-ARS(X)  av-l 

9  “HP  ^ 


DEEP  OCEiVN 
RECOVERY 


EMERGENCY  & 
ROUTINE  TOEING 


MRCfLiFT 

RECOVERY 


NATIONAL  RE  SFONSE 


OIL  POLLUTION 
ABATEMENT 


Figure  19.  T-ARS(X)  OV-1.  Modified  from  [38] 


G.  TOWING  AND  SALVAGE  ARCHITECTURE  INITIATION 

The  future  Towing  and  Salvage  Platform  Structure  architecture  is  envisioned  to 
be  a  single-hull  replacement  for  the  present  T-ARS  and  T-ARS  class  ships,  making  the 
top-level  components  of  an  architecture  comprised  of  legacy  systems  already  fulfilling 
some  capabilities.  Strictly  speaking,  the  architecting  process  does  not  start  by  defining 
the  form  of  the  future  system  as  a  ship,  aircraft,  or  any  other  vehicle;  however,  the  end 
item  here  has  already  been  named  a  T-ARS(X)  class  of  ship. 

In  general,  system  physical  hierarchical  relationships  can  be  developed  in  any 
predefined  way,  one  of  which  is  shown  in  Figure  20,  which  depicts  a  generic 
representation  of  a  hierarchy  of  elements  within  a  system.  Each  physical  element 
functions  to  implement  a  task  to  achieve  a  mission.  Note:  Although  CORE  uses  the  term 
"component,"  this  particular  element  can  represent  any  of  the  physical  elements  in  the 
example  hierarchy. 
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Product 
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Subsystem 
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Assemblies 
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Subassemblies 

Subcomponents 

i 

Parts 


Elements  of  the  system  may  include  hardware,  software,  and  humans  dependent  on  the  system  definition. 

Figure  20.  Hierarchy  of  elements  within  a  system  From  [39] 


The  initialization  of  the  architecting  process  in  this  case  starts  at  the  Component 
element  class  and  how  each  attribute  is  exhibited  by  Performance  characteristics 
identified  by  SUPSALV.  The  Expanded  Ship  Work  Breakdown  Structure  (ESWBS) 
(Figure  21)  will  serve  the  basis  for  accounting  for  a  complete  ship  decomposition 
hierarchy,  since  this  is  the  standard  physical  element  language  used  by  naval  architecture 
for  combatant  ship  design. 
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Figure  21.  Expanded  Ship  Work  Breakdown  Structure 


The  ESWBS  is  based  on  the  Ship  Work  Breakdown  Structure  (SWBS)  to  define 
and  categorize  to  boundaries  in  ship’s  systems  and  SoS.  The  expanded  level  of  detail  is 
designed  to  enhance  preliminary  and  detail  designs  for  a  baseline.  As  further 
development  continues,  the  ESWBS  system  becomes  the  first  five  digits  in  the  Functional 
Group  Code  (FGC).  The  FGC  is  provided  to  the  shipbuilder  as  a  functionally  oriented 
breakdown  sequence  of  a  system.  The  ESWBS  Structure  shown  in  Figure  21  is  the  ten 
major  SWBS  sub-groupings  serving  as  the  second  level  of  component  class  for  this 
architecture.  Subsequently,  the  groups  provide  other  functions  as  well.  The  groups,  as  a 
whole,  classify  total  weight-related  cost  for  ship  Condition  A  (Light  ship  without 
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margin).  Groups  100  through  700  equate  to  hardware  cost  and  weight.  Combining 
Groups  100-700  with  800  and  900  will  equal  construction  cost  [40]. 

Each  component  is  entered  into  CORE  by  clicking  on  the  Component  file  and 
entering  it  in  the  pop  up  New  Component  window.  Component  element  Relationships 
are  developed  by  double  clicking  on  the  element  in  the  element  window  and  populating 
the  asPropertySheet  window  that  pops  up.  The  Relationships  window  portion  lists  each 
relationship  that  can  be  identified  with  the  element  selected.  Each  of  the  ESWBS  groups 
mentioned  was  identified,  in  addition  to  a  few  of  the  elements  (as  defined  by  [40])  in 
CORE  to  begin  the  first  iteration  in  the  architecture.  After  all  elements  were  identified  in 
the  asPropertySheet,  the  asER  (Element  Relationship)  illustrate  the  relationships  of  the 
component  element  highlighted  (Figure  22). 
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Figure  22.  CORE  snapshot  of  Component  construction 


The  next  step  performed  was  to  enter  the  Requirements  defined  by  SUPSALV 
[41].  They  are  listed  in  Tables  12  and  13.  Each  performance  characteristic  (as  a 
requirement)  is  entered  in  the  same  manner  as  the  Component  elements  were  defined. 
These  elements  are  linked  to  the  Component  elements  via  the  asPropertySheet  in  the 
linking  them  as  'exhibited  by'  attributes.  These  Characteristics  are  not  inclusive  to  all 
parameters  needed  to  design  a  complete  vessel;  an  iterative  development  populating  each 
of  the  classes  needs  to  be  performed.  To  accomplish  this,  each  performance 
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characteristic  is  established  as  the  top  level  requirement  in  Baseline  1.  Following  Figure 
24,  the  spiral  development  for  ship  design  (skipping  over  those  spokes  not  intended  for 
Towing  and  Salvage)  will  designate  the  hierarchy  of  these  requirements.  After  a  series  of 
requirements  decompositions  are  performed,  the  actual  level  of  the  specified 
requirements  will  be  identified. 


Figure  23.  Iterative  nature  of  ship  design  From  [42] 
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CHARACTERISTIC 

(THRESHOLD/OBJECTIVE) 

Speed  (knots  sustained) 

15/20 

Bollard  Pull  (tonnes) 

150;  T=0 

Navy  Personnel  Accommodation 

42;  T=0 

Civilian  Crew  Accommodation 

15;  T=0 

Positioning/Mooring 

DP-2/DP-3.  +  4  Point  Moor;  T=0 

Endurance 

8,000  nm  @  8  kt/12,000  @10  kt 

Unobstructed  Deck  Space;  AFT 

3600  ft2;  T=0 

Crane;  Lift  Capacity  Min. 

(Amidships/ Amidships  +  Stern) 

110  Tonnes  SWL 

Crane;  FWD 

Min.  10  Tonnes  SWL;  T=0 

Towing 

-  Twin  Drum 

-  3”  wire  x  3,500  ft 

-  Traction  Winch 

-  Shark  Jaws 

-  Auto-tow  Pins 

-  Portable  Tow-bow 

R  &  A  Firefighting 

4  monitors  @  10K  +  GPM  Min.  Each; 

AFFF  Capable;  T=0 

Interoperability 

Deck  Loading  and  Ship  Service 

Support  For: 

-  FMGS 

-  Deep  Ocean  Search  and  Recovery 

-  SAT-FADS 

-  SRDRS  (RCS  only/TUP  with  ADS) 

-  Submarine  Salvage  Support 

Table  12.  Primary  Performance  Characteristics.  From  [41] 
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CHARACTERISTIC 

(THRESHOLD/OBJECTIVE) 

Ice  Classification 

Al;  T=0 

Unobstructed  Deck  Space;  Fwd 

720  ft2  ;  T=0 

Bow/Stem  Roller  System 

Heavy-lift  and  Beach  Gear 

Capable/Interoperable 

Propulsion  System 

“Big/Little  Brother”  Arrangement 

SNDL  Recompression  Chamber 

Modular/Fixed 

Diver  Support  Boat  (distinct  from 

lifeboat) 

OneRHIB  (7m/llM) 

Compressed  Air 

Non-DLSS;  to  meet  ship  service 
support  function 

Salvage  Equipment  Stowage 
(Below  Decks) 

3000  ft2;  T=0 

Fabrication 

-  Machine  Shop 

-  Wood  Shop 

Deck  Fastener  System 

TBD  (ISO  container;  Tie-down; 
and/or  Baxter  Bolt) 

Line/Wire  Stowage 

To  Towing  Mission 

Portable  Bulwarks 

Bow  &  Stem 

Communications 

T-ARS  50  Functionality 

Environmental 

-  Ambient  Air  (-20°F  to  130°F) 

-  Sea  Water  (28°F  to  100°F) 

Survivability 

Commercial  Salvage  Standards  (e.g.,  ABS 
classification) 

Table  13.  Secondary  Performance  Characteristics.  From  [41] 


An  architecture  element  class  named  “Aircraft  Salvage  in  less  than  1 80  fsw”  was 
generated  with  the  list  of  requirements.  Each  element  class  was  populated  to  identify  the 
requirements  given  to  the  components  (listed  from  the  ESWBS)  and  establish  a  Baseline 
1.  This  entailed  connecting  the  architecture  to  an  OperationalNode  by  the  ‘composed  of 
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attribute.  OperationalNodes  are  considered  as  the  actors  in  performing 
OperationalActivity,  and  are  illustrated  in  the  OV-1  as  00C,  MDSU,  MSFSC,  and  ESSM. 
The  elements  were  left  at  a  high  level,  but  should  be  further  explained  as  lower  levels  — 
such  as  00C1,  MDSU-2,  and  ESSM  Port  Hueneme  —  to  fully  gain  context  of  the 
architecture.  These  lower  level  elements  are  considered  ‘children’  and  would  have  the 
relationship  of  ‘built  from.’  In  CORE,  OperationalActivities  represent  Capabilities  and 
are  behavior  entities.  For  example,  Execute  Salvage  Operations  capability  will  have  00C, 
MDSU,  and  MSFSC  as  OperationalNodes  and  achieve  Salvage  Aircraft  Mission  element. 
Figure  24  shows  a  rough  skeleton  schema  for  “Aircraft  Salvage  in  less  than  180  fsw.”  A 
diagram  such  as  this  could  serve  as  a  starting  point  for  discussion  on  how  one 
requirement  is  needed  to  perform  a  capability.  This  could  be  traced  back  to  a  policy  or 
procedure  listed  in  the  Guidance  element  class.  One  example  would  be  a  source  such  as 
Mission  Essential  Task  List  (METL). 


Figure  24.  Rough  Skeleton  Schema  for  Aircraft  Salvage  in  less  than  180  fsw. 
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H.  HIERARCHICAL  AND  ELEMENT  ARCHITECTURE  RELATIONSHIPS 


A  hierarchical  relationship  of  any  element  can  be  composed  within  CORE  easily 
by  configuring  them  in  the  properties  tab.  Figure  25  shows  a  small  piece  of  the  Auxiliary 
Systems  breakdown  to  find  cranes  within  the  ESWBS.  The  benefit  to  this  is  the  naval 
architect  who  will  be  using  the  products  from  CORE  as  a  basis  for  the  next  level  of 
decomposition.  As  each  function  is  decomposed  to  lower  levels,  the  lower  level 
functions  can  be  allocated  to  the  lower  level  functions.  Figure  26  illustrates  how  the 
lower  level  functions  Salvage  Lift  and  AFT  Deck  Diving  Operations  are  performed  by 
the  Component  Cranes.  The  Element  Relationships  aid  in  showing  how  each  element 
class  is  connected  to  each  other  and  equips  the  architect  in  linking  ideal  relationships. 
This  helps  in  giving  a  better  visualization  of  the  architecture  and  mapping.  For  example, 
Figure  27  maps  requirements  to  the  function  (Salvage  Lift)  for  a  better  explanation  of 
how  they  relate  to  the  capabilities  of  the  architecture.  Correct  decomposition  and  element 
relationship  mapping  will  greatly  influence  tradeoffs  in  further  discussions.  The  decision 
maker  has  a  better  perspective  of  how  the  system  is  developed  and  can  be  mapped  back 
to  a  capability  need. 


Figure  25.  Component  Hierarchy  from  ESWBS  as  seen  in  CORE. 
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Figure  26.  Element  Relationship  in  CORE  for  Cranes 
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Figure  27.  Element  Relationship  for  Salvage  Lift  function. 


56 


I. 


DODAF  1.5  VIEWS  FROM  CORE 


CORE  can  document  the  architecture  product  as  a  Rich  Text  Format  (RTF),  via 
what  they  call  “scripts.”  Each  script  generates  a  standard  DODAF  diagram,  a  table  of  the 
repository  contents,  or  and  external  file  referenced  by  an  ExtemalFile  element.  The 
DoDAF  vl.5  view  scripts  are  designed  to  be  flexible  in  order  to  support  any  later 
iteration  completed  by  further  architecting  processes  to  produce  views  for  the  customer. 
Each  time  the  script  is  run,  it  is  checked  for  errors,  ensuring  traceability  [35], 

1.  The  OV-5  Activity  Model  for  Execute  Salvage  Operations 

One  script  produced  by  the  rough  architecture  skeleton  of  “Aircraft  Salvage  in 
less  than  180  fsw”  is  the  OV-5  activity  model  shown  in  Figure  28.  The  “Execute  Salvage 
Operations  Hierarchy  Diagram”  illustrates  this  ‘children’  OperationalActivities  of  the 
user  selected  OperationalNode(s).  This  activity  model  graphically  structures  the 
activities  in  a  probable  activity  hierarchy  to  enable  the  architect  to  understand  the  level  at 
which  function  is  needed. 


Figure  28.  Execute  Salvage  Operations  Hierarchy  Diagram 


Figure  29  is  the  IDEFO  diagram  depicting  which  OperationalNodes  perform 
OperationalActivity.  Note:  There  is  overlap  within  the  activities,  which  are  intended  to 
demonstrate  those  actions  performed  by  humans.  The  term  ‘function’  refers  to  those 
actions  performed  by  systems. 
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Figure  29.  Execute  Salvage  Operations  IDEFO  Diagram 


2.  The  SV-4  Activity  Model  for  Aircraft  Salvage 

The  SV-4  view  documents  the  user-selected  function  and  its  children.  Figure  30 
is  the  Aircraft  Salvage  Hierarchy  diagram.  Figure  31  goes  on  to  show  the  IDEFO 
diagram;  connecting  the  components  to  the  functions  within  ‘Aircraft  Salvage.’  A  SV-4 
view  is  the  OV-5  for  systems;  documenting  system  data  flows  between  functions. 
Adequate  functional  decomposition  within  these  views  will  ensure  sufficient  level  of 
detail  for  system  design. 
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Figure  30.  Aircraft  Salvage  Hierarchy  Diagram 


Figure  31.  Aircraft  salvage  IDEFO  Diagram 
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J.  SUMMARY 

This  chapter  outlined  a  systems  architecting  process,  and  illustrated  the  manner  of 
how  a  legacy  system  is  architected  in  the  context  of  a  SoS  from  a  given  set  of  stakeholder 
information  —  in  this  case,  from  the  U.S.  Navy  Diving  and  Salvage  community.  The 
process  is  integrated  with  the  front  end  of  the  traditional  systems  engineering  process. 
The  architecting  process  is  partitioned  from  the  systems  engineering  process,  primarily 
due  to  the  differences  in  the  approach  to  the  problem,  which,  in  the  architecting  stage, 
requires  inductive  reasoning,  abstract  conceptual  thought,  and  a  way  of  dealing  with 
stakeholder  needs  that  do  not  play  to  the  typical  analytical  strengths  of  engineers.  The 
process  described  is  deployed  in  the  context  of  the  integrated  architecture  development 
philosophy  in  the  DoD  JCIDS  process,  and  the  DODAF. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

DoD  has  recently  changed  to  a  philosophy  of  developing  integrated  architectures 
to  meet  capability  needs.  The  JCIDS  process  provides  the  context  to  identify  capabilities 
and  capability  gaps  to  shift  toward  capability-based  planning.  The  DODAF  and  Naval 
Architecture  Elements  Reference  Guide  (NAERG)  provide  a  basis  for  defining  standard 
architectures  for  DoD  systems  and  SoS.  As  the  Navy  changes  its  approach  to  developing 
systems  —  from  a  bottom  up,  stove-piped  design  to  a  joint  service  strategic  vision  —  a 
systems  and  SoS  architecting  process  definition  and  implementation  is  needed. 

What  has  been  illustrated  is  a  systems  architecting  approach  that  is  traceable  from 
military  strategy  to  system  requirements  in  a  way  that  produces  architecture  that  can  be 
created,  defined,  communicated,  recreated,  rerun,  and  moved  around  as  needed  to  explore 
the  design  possibility  space  in  an  interactive  manner  focused  on  stakeholder  needs.  A 
computational  software  tool,  CORE,  has  been  used  to  accomplish  this.  CORE  is  a 
software  tool  that  can  be  used  to  link  element  relationships  to  give  the  full  visualization 
required  for  stakeholders  to  make  decisions.  In  CORE,  this  can  be  revised  for 
investigation  and  added  throughout  the  acquisition  process.  The  DODAF  views  are 
generated  within  CORE,  and  Scripts  are  developed  for  system  and  subsystem 
specifications  in  a  RTF  for  presentation,  review,  and  analysis  of  the  architecture. 

The  Recapitalization  of  a  Towing  and  Salvage  vessel  was  used  as  an  example  in  a 
‘middle  out’  process.  The  beginning  elements  known  were  that  the  architecture  was 
going  to  be  a  ship  and  a  list  of  requirements.  The  architecture  was  iterated  using  the 
CORE  DODAF  1.5  schema  to  produce  example  scripts  that  could  be  used  in  DODAF  1.5 
views.  This  process  provides  a  useful  method  to  allow  architecting  of  the  diving  and 
salvage  fleet  that  can  meet  the  capabilities  needed  not  only  by  the  Navy  Supervisor  of 
Diving  and  Salvage  in  an  operational  and  strategic  sense,  but  also  in  the  context  of  the 
needs  of  the  joint  service  architecture  for  accomplishing  warfighting  and  business  goals. 
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B.  RECOMMENDATIONS 


The  process  outlined  and  implemented  on  the  diving  and  salvage  platform 
provided  the  basis  for  the  creation  of  an  architecture  and  the  related  products.  The 
development  of  the  overall  diving  and  salvage  architecture,  and  the  demonstration  of  the 
use  of  the  architecture  for  strategic  and  operational  decision  making  should  be 
accomplished.  This  includes: 

•  Developing  an  architecture  that  is  populated  to  the  extent  that  elements 
include  enough  description  to  demonstrate  the  use  for  operational  and 
strategic  planning,  including  the  need  for  trade  offs  for  acquiring  new 
platforms  or  contracting  of  outside  resources 

•  Exercising  the  architecture  in  a  dynamic  sense  to  create  options  for 
planning  and  design 

•  Integrate  the  architecting  process  and  respective  tools  ( e.g .,  CORE)  with 
ship  design  tools  {e.g.,  ASSET,  POSSE)  in  order  to  allow  a  more 
quantitative,  physics-based  analysis  of  ship  platform  development,  and 
connect  the  traditional  ship  design  process  to  the  stakeholder  need. 

•  Expand  the  process  scope  to  core  warfighting  capabilities  and  business 
capabilities,  such  as  combatant  ships,  aircraft,  ground  vehicles,  and  system 
command  organizations. 

Continuing  the  development  of  the  architecting  process  will  facilitate  the  ability  to 
operate  and  plan  the  implementation  of  a  Navy  diving  and  salvage  capability,  but  will 
also  lead  to  implementations  in  other  Navy  ship  and  system  development  organizations. 
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